Tarjeta de Crédito: Flujo de pago

En la plataforma de MENU, las tarjetas de crédito representan un tipo de método de pago diferente. Al igual que con todos los tipos de métodos de pago, la disponibilidad de los pagos con tarjeta de crédito se especifica a nivel de marca y local. Allí figuran todos los tipos de tarjetas, junto con la definición de una o varias instancias de procesadores de pagos con tarjeta de crédito. La plataforma de MENU admite los siguientes tipos de tarjetas de crédito:

• VISA 

• MasterCard

• American Express 

• Maestro 

• JCB

Para poder procesar los pagos con tarjeta de crédito, cada instancia de los procesadores de pagos debe implementaruna interfaz para las siguientes acciones:

• Registro de la tarjeta de crédito

• Eliminación de la tarjeta de crédito

• Autorización de la transacción

• Liquidación de la transacción

• Anulación de la transacción

• Reembolso de la transacción

De manera opcional, las instancias de procesadores de pagos pueden admitir otras acciones, como obtener y buscar transacciones, registrar clientes, etc.

Los tipos de procesadores de pagos de la plataforma de MENU que implementan la interfaz de pago con tarjeta de crédito son los siguientes:

• Saferpay 

• Toast 

• Adyen 

• FAC 

• Transbank 

• FirstData

• Cybersource

• Paymaya

• Paystack

Los métodos de pago (tipos de tarjetas de crédito) se pueden configurar por procesador de pagos. No todos los procesadores de pagos admiten los mismos métodos de pago. En general, todos ellos admiten al menos Mastercard y VISA.

Registro de la tarjeta de crédito

Los clientes de MENU registrados pueden agregar varios métodos de pago a su cuenta. La plataforma de MENU cumple con la normativa PCI. MENU cumple con la normativa PCI en el nivel de DSS SAQ-A. Para obtener más información al respecto, accede al siguiente enlace. Según el procesador de pagos y el tipo de app, los datos de la tarjeta de crédito se introducen a través de una interfaz especializada como campos cifrados, campos alojados o una página alojada que se muestra en iFrame o en una vista web. Una vez que los datos de la tarjeta se recopilan y envían correctamente, el procesador de pagos devuelve un token, un identificador de tarjeta de crédito no confidencial, que se almacena en la base de datos y se utiliza para pedidos y pagos posteriores. Dado que el cliente puede tener varios métodos de pago asociados a su cuenta, siempre debe haber uno solo marcado como opción predeterminada.

Si hay varios procesadores de tarjetas de crédito disponibles para la marca y la app activa, se deben registrar las tarjetas de crédito para cada procesador de pagos. Según cómo se gestione el registro de varias tarjetas, hay dos flujos para ello: directo y de proxy.

Flujo directo

La app del cliente envía los datos de la tarjeta de crédito directamente a cada punto final de registro del procesador de pagos de manera independiente. (Flujo aplicado a las apps móviles).

Flujo de proxy

Flujo específico de la app del cliente que depende de iFrame para mostrar el formulario de tarjeta de crédito, como las apps web. En lugar de mostrar un formulario de tarjeta para cada procesador de pagos, se utiliza un servicio de proxy de pago para registrar la tarjeta de crédito temporalmente y, luego, los datos de la tarjeta se reenvían a cada uno de dichos procesadores.

Eliminación de la tarjeta de crédito

Los clientes pueden eliminar las instancias de métodos de pago que hayan agregado previamente a su cuenta. Cuando se elimina un método de pago, también se eliminan todos los procesadores de pagos relacionados con las instancias de ese método. En cuanto al procesador de pagos con tarjeta de crédito, esto debe incluir eliminar todos los datos de la tarjeta de crédito de la cuenta de dicho procesador.

Autorización y liquidación de la transacción

Los pagos forman parte del proceso de creación de un pedido que se inicia con una solicitud. Los pagos se realizan siempre antes de que un pedido se envíe a la integración POS/Printer, pero la secuencia exacta de autorización/liquidación depende del contexto del pedido, es decir, del tipo de pedido y de la hora en que se recoge. En el caso de los pedidos rápidos (es decir, Dine-In, Quick Service, Pick & Pay, Take-Out, Delivery), siempre se debe autorizar primero el importe total del pedido, y el importe se envía para su liquidación solo después de que el pedido se envíe correctamentea POS/Printer. Por otro lado, en el caso de los pagos de pedidos demorados (Take-Out, Delivery), se debe saldar el importe total del pedido justo después de que se cree y antes de que se envíe a POS/Printer. La responsabilidad de gestionar el contexto de los pedidos y aplicar el flujo correcto de autorización/liquidación recae en el servicio de pago, no en el procesador de pagos. La implementación del procesador de pagos con tarjeta de crédito solo debe admitir la autorización y liquidación de las transacciones.

Dado que los pedidos están disponibles tanto para los clientes registrados como para los clientes invitados, existen dos flujos de pago principales en función de si hay una tarjeta de crédito registrada previamente o no: flujo directo y flujo de pago “Init”.

Flujo de pago directo

Este flujo se basa en un método de pago previamente registrado y no requiere que el cliente introduzca ningún dato de la tarjeta de crédito. Después de realizar el pedido correctamente, el método de pago utilizado se convierte en la opción predeterminada para otros pagos posteriores.

Las operaciones de pago creadas a través de este flujo se tratan como iniciadas por el comercio (Merchant Initiated, MIT).

Flujo de pago “Init”

Este flujo no requiere un método de pago previamente registrado, lo que permite que los clientes invitados realicen pagos, pero también puede aplicarse a los métodos de pago registrados. 

Las operaciones de pago creadas a través de este flujo se tratan como iniciadas por el cliente (Client Initiated, CIT), lo que hace que este flujo sea compatible con 3DS . Para obtener más información al respecto, consulta el siguiente artículo.