Resolviendo el problema del débito Interac: por qué los procesos de pago personalizados en aplicaciones web fallan en los comercios canadienses

Un proceso de pago personalizado en una aplicación web falla en un comercio físico canadiense por una razón estructural: no puede procesar el débito Interac en el mostrador. Los procesos de pago que generan los creadores de aplicaciones sin código y con IA son formularios de tarjetas de crédito en línea. El débito Interac en una tienda física es un sistema de pago diferente que funciona en la red de débito nacional de Canadá a través de hardware de terminal certificado (lectores de tarjetas aprobados para chip, PIN y pago sin contacto). Un formulario de navegador no tiene acceso a ese hardware, por lo que cada cliente de débito presencial tiene que pagar de otra manera o no pagar en absoluto. En Canadá, esto no es un caso aislado: los canadienses completaron más de 6,500 millones de transacciones de débito Interac en un solo año, y los productos de Interac gestionan alrededor de 18.6 millones de transacciones cada día¹.

Las vías de pago cambian rápidamente; los datos de la red en esta publicación son precisos a la fecha de publicación y vale la pena volver a verificarlos antes de desarrollar en torno a ellos.

¿Por qué un pago web estándar no puede procesar el débito Interac?

Porque el pago web estándar fue diseñado para pagos con tarjeta no presente (transacciones en las que nunca se lee la tarjeta física), y el débito Interac en una tienda es con tarjeta presente por definición. Una página de pago alojada o un enlace de pago, el patrón de Stripe y PayPal que copian la mayoría de las herramientas creadas en EE. UU., recopila un número de tarjeta en el navegador y lo envía a las redes de tarjetas de crédito globales. Eso funciona en cualquier parte del mundo para pedidos en línea. No hace nada por el cliente que está parado frente a su mostrador, porque el débito canadiense en tienda se enruta a través de la red Interac mediante un lector certificado, no a través de un formulario web.

El aspecto en línea de Interac es más limitado de lo que la mayoría de los comerciantes suponen. Interac Online, la antigua opción de pago desde su cuenta bancaria en los pagos web, se suspendió en mayo de 2024². Hoy en día, pagar en línea con débito Interac funciona a través de Apple Pay y Google Pay en bancos y comercios participantes³, y las tarjetas de marca compartida (tarjetas de débito que llevan tanto Interac como Visa Débito o Débito Mastercard) recurren a las redes globales de tarjetas cuando se introducen en un formulario. Por lo tanto, un pago web genérico puede capturar parte del gasto de débito canadiense en línea. Lo que nunca podrá hacer es capturar el pago sin contacto en la caja registradora.

¿Cómo lo limitan los creadores sin código a pagos únicamente con tarjeta?

Ofrecen exactamente una única solución de pago: un formulario de tarjeta en línea integrado o un enlace de pago alojado. Pídale a un creador de aplicaciones web con IA una pantalla de pago para un comercio y obtendrá algo que se parece a una, como explicamos en ¿Se puede construir un POS con Lovable o Replit? El paso de pago subyacente es un formulario de tarjeta exclusivamente digital, porque esa es la única integración que el creador sabe conectar. Para un comercio canadiense, esto genera tres problemas:

• Cada venta en el mostrador se convierte en una transacción con tarjeta no presente escrita a mano: la forma más expuesta al fraude de procesar un pago que podría haber sido un simple toque sin contacto.

• Los clientes que prefieren el débito no pueden pagar de la forma en que lo hacen habitualmente. Entregar una pantalla para escribir el número de tarjeta a alguien que quería acercar una tarjeta de débito es una excelente manera de perder la venta y al cliente.

• No hay una solución de hardware. Los navegadores no pueden controlar un teclado PIN certificado, por lo que ninguna cantidad de instrucciones añadirá un lector de tarjetas a una aplicación web.

La solución provisional obvia es colocar un terminal independiente de un gran proveedor de POS junto a la aplicación web personalizada. Ahora gestiona dos sistemas. El pedido reside en su aplicación, el pago en el panel del proveedor del terminal, los reembolsos se realizan en un lugar y el inventario en otro, y cada tarde alguien concilia (hace coincidir ambos conjuntos de registros al centavo) a mano. Hemos escrito sobre cómo las soluciones provisionales se consolidan en el propio sistema; esta es la que se consolida más rápido, porque hay dinero de por medio.

¿Qué se necesita para aceptar el débito Interac en el mostrador?

Cuatro cosas, funcionando como un solo sistema:

• Hardware de terminal certificado que lea chip, PIN y pago sin contacto.

• Un procesador de pagos certificado en la red Interac para enrutar y liquidar el débito nacional.

• Infraestructura de cumplimiento: la gestión de PCI (las normas de seguridad de datos de la industria de tarjetas) y EMV residen en la pila certificada, no en el código de su aplicación.

• Una conexión en vivo entre su software de pago y el terminal, de modo que el importe, la propina, el reembolso y el recibo fluyan a través de un único registro de transacción.

El cuarto elemento es donde se estancan las aplicaciones web personalizadas. Los tres primeros se pueden comprar; la conexión entre un diseño de pago personalizado y las vías de pago conformes debe ser desarrollada por ingenieros, y es un trabajo más grande que el propio diseño. Lo que realmente incluye la infraestructura de pagos es una lista más larga de lo que la mayoría de los planes de autoconstrucción presupuestan.

¿Cómo soluciona esto un motor financiero integrado?

Al hacer que el diseño personalizado y las vías de pago formen parte de la misma plataforma, de modo que ya se comuniquen entre sí. Cuando la pantalla de pago que diseña y las vías que mueven el dinero comparten un mismo sistema, una venta en el mostrador se envía a un lector certificado, un pedido en línea se procesa a través del pago web y ambos terminan en los mismos pedidos, inventario e informes. Nada que integrar, nada que conciliar a mano.

Ese es el enfoque que adopta Final: describa el proceso de pago que desea en una instrucción (o conecte su propia IA a través de MCP) y el flujo que construye se ejecutará en Final Pay con hardware de terminal certificado, de modo que una tarjeta de débito acercada al lector en el mostrador y un pago con tarjeta en línea terminen en los mismos libros de contabilidad. El diseño sigue siendo suyo para modificarlo; la capa del dinero sigue siendo determinista (da la misma respuesta correcta en todo momento). La misma división se muestra en lo que la IA hace mal al diseñar un proceso de pago: deje que la IA dé forma al flujo, nunca deje que improvise el pago.

Entonces, ¿por qué los procesos de pago personalizados en aplicaciones web fallan en los comercios canadienses?

Porque resuelven la mitad equivocada del problema. Generan la pantalla y omiten las vías de pago, y en Canadá las vías de pago en el mostrador son el débito Interac a través de hardware certificado. Un proceso de pago que solo puede ejecutar formularios de tarjetas en línea convierte cada venta presencial en su peor tipo de transacción y ahuyenta por completo a los clientes de débito. La regla general: si su pantalla de pago no puede aceptar una tarjeta de débito por contacto, es un formulario de comercio electrónico, no un proceso de pago para un comercio físico.

Si está evaluando una construcción personalizada, comience con lo que realmente implica un sistema POS personalizado, luego observe cómo un flujo creado mediante instrucciones maneja el aspecto del pago antes de comprometerse a conectarlo usted mismo.