¿Qué tan difícil es crear tu propia aplicación de Tap to Pay? (Lo intentamos)

Más difícil de lo que sugieren los folletos de los SDK, y la dificultad en su mayoría no es el código. Lanzamos Tap to Pay en la aplicación de Final POS, por lo que esta respuesta proviene de la experiencia real, no de leer documentación. Si quieres crear tu propia aplicación de Tap to Pay, planifica un proyecto de software corto envuelto dentro de un proyecto de permisos mucho más largo: una alianza con un procesador de pagos, una autorización manual de Apple o una evaluación de laboratorio en Android, y una revisión de la aplicación, todo antes de tu primer pago real.

Una advertencia rápida: las reglas de las plataformas y de la industria de las tarjetas cambian a menudo. Todo lo que se presenta a continuación es preciso a la fecha de publicación, así que considera los detalles como una instantánea.

¿Qué hace realmente una aplicación de Tap to Pay?

Tap to Pay convierte el propio teléfono en el lector de tarjetas. Sin terminales ni adaptadores: el cliente acerca una tarjeta sin contacto o una billetera digital como Apple Pay o Google Pay directamente al dispositivo del comerciante, y el pago se procesa a través del chip NFC del teléfono (la radio de corto alcance utilizada para la tecnología sin contacto). Si la terminología te resulta confusa, hemos desglosado la diferencia entre los pagos móviles sin contacto y Tap to Pay en dispositivos móviles.

Aquí está la trampa. Leer una etiqueta NFC es realmente un proyecto de fin de semana; los aficionados lo hacen constantemente. Leer una tarjeta de pago es un deporte diferente. Las tarjetas hablan EMV (el protocolo de chip de la industria de tarjetas), los datos de la tarjeta deben permanecer cifrados de extremo a extremo y solo el software certificado tiene permitido tocarlos.

¿Por qué no puedes simplemente leer la tarjeta tú mismo?

Porque cada capa de la estructura requiere autorización antes de que tu código pueda ejecutarse en público.

• Apple no otorga a las aplicaciones acceso directo al NFC de pago. Debes usar su framework ProximityReader, que se encuentra detrás de una autorización de Tap to Pay en el iPhone (un permiso especial que Apple otorga caso por caso). Apple también requiere que te integres con un proveedor de servicios de pago (PSP) compatible (la empresa que realmente mueve el dinero). El PSP suministra las configuraciones de lector certificadas que se cargan en el dispositivo del comerciante y asume la carga de la certificación.

• Android ofrece a los desarrolladores un acceso NFC más abierto, pero una aplicación de aceptación de pagos aún debe ser evaluada por un laboratorio independiente reconocido por el PCI conforme al estándar PCI MPoC (las normas de seguridad de la industria de tarjetas para teléfonos que actúan como terminales de pago).

• Debajo de ambas plataformas, necesitas una relación de adquisición: un procesador dispuesto a liquidar el dinero de tus comerciantes, con las reglas de las redes de tarjetas incluidas.

Nada de esto se puede resolver a la fuerza escribiendo mejor código. Se trata de papeleo, contratos y colas de revisión.

¿Cómo es el proceso de aprobación en el iPhone?

Según los requisitos publicados por Apple, el camino es el siguiente: tener una cuenta de Apple Developer a nivel de organización (el titular de la cuenta presenta personalmente la solicitud), asociarse con un PSP compatible para tus regiones, solicitar la autorización, integrar la API ProximityReader o el SDK de tu PSP, seguir las pautas de diseño de Apple para la pantalla de pago y enviar la aplicación para su revisión. La documentación de Apple también señala que la función solo funciona en países y regiones compatibles, por lo que la disponibilidad en sí se decide por ti, mercado por mercado.

Lee esa lista de nuevo como fundador o comerciante en lugar de como desarrollador. Ninguno de los pasos es "escribir la función". La función es la parte fácil; la autorización es la barrera de entrada.

¿Hacia dónde se dirige el trabajo una vez que el pago funciona?

Un pago aprobado te da un cobro, no un punto de venta. En el momento en que el dinero se mueve, todo lo que rodea al pago debe ser correcto: el carrito contra el que se liquida, los impuestos en el recibo, la ruta de reembolso y los reportes que concilian (cada dólar emparejado con una venta, todos los días). Encontramos la misma brecha cuando analizamos si se puede crear un POS con Lovable o Replit: generar una interfaz es rápido, pero la capa comercial subyacente es lo que consume el calendario.

Tap to Pay también trae sus propias peculiaridades operativas. En nuestra implementación, la venta debe registrarse en el mismo dispositivo que recibe el pago, y solo funciona en la aplicación nativa, nunca en un navegador. Restricciones como esa no aparecen en ningún folleto. Las descubres, diseñas soluciones para ellas y luego escribes el artículo de ayuda. Y cuando un teléfono en el mostrador deja de ser suficiente, de todos modos entras en decisiones reales de hardware.

Entonces, ¿qué tan difícil es crear tu propia aplicación de Tap to Pay?

Difícil de una manera específica: la programación es la parte más pequeña, mientras que la alianza con el procesador, la autorización de Apple, la certificación de laboratorio en Android y la revisión de la aplicación constituyen la mayor parte, y ninguno de ellos responde al esfuerzo de ingeniería. Para nosotros valió la pena, porque una plataforma de POS distribuye ese costo entre cada comerciante que la utiliza. Tap to Pay es ahora un botón de pago que nuestros comerciantes activan, y aceptar un pago con Tap to Pay es una rutina de mostrador de cinco pasos. Si los pagos son tu producto, superar este proceso es el precio de entrada. Si los pagos son solo la forma en que cobras, crear tu propia aplicación de Tap to Pay no tiene sentido financiero; la versión terminada ya existe dentro de las aplicaciones de POS, y las tarifas es donde reside la verdadera comparación.

Regla general: si una función necesita el permiso de otra persona para existir, ninguna cantidad de código inteligente la acortará.