Resumen del backend de pagos
Un backend de pagos es tu propia copia de la API de un proveedor de pagos. A esos proveedores se les suele decir PSP, por payment service provider, y la app también usa esa palabra.
El backend recibe las llamadas que tu integración ya hace, en las mismas rutas, y responde con las formas y los códigos de estado del propio PSP.
Lo que lo hace útil es que guarda estado. Autoriza un pago, captúralo en una llamada posterior, y después reembolsa una parte: sigue siendo un solo pago de punta a punta, no tres respuestas sin relación.
Ese estado dura poco a propósito. Un pago y su historia se quedan alrededor de un día, una sesión de checkout alojada 15 minutos, y un desafío de 3D Secure 5. Alcanza para una corrida de tests o una tarde de depuración, y no es un lugar para guardar registros.
El ciclo de vida de un pago
Un pago pasa por los estados que usa el proveedor:
- Autorizar retiene el dinero. Un pago que no necesita captura aparte se liquida al instante, como trabajan algunos proveedores.
- Capturar lo cobra. Captura el monto entero, una parte, o varias veces hasta lo autorizado.
- Reembolsar lo devuelve, entero o en partes.
- Cancelar libera una autorización que nunca se capturó.
- Ajustar sube o baja una autorización antes de la captura.
Se modelan dos bordes porque las integraciones reales chocan con ellos: reembolsar un pago que nunca se capturó, que en realidad lo cancela, y cancelar uno que ya se capturó, que en realidad lo reembolsa. Una autorización de monto cero para verificar la tarjeta también funciona.
No todos los PSP hacen todo esto, y el backend no finge otra cosa. Cada marca declara qué soporta, versión por versión, y la app lo muestra en la pestaña Resumen de la marca como capacidades del tipo capture, partialCapture, partialRefund, threeDS e idempotency.
3D Secure sin una persona
Los pagos con tarjeta que necesitan autenticación corren el flujo 3DS2 completo. Según lo que pidas, un pago puede:
- pasar sin fricción, sin ningún desafío,
- recoger primero una huella del dispositivo, y dejar que eso decida si se desafía a quien paga,
- o frenar en un desafío, como un código de un solo uso, una redirección, o una aprobación en la app del banco.
El backend sirve la página del desafío, así que un test lo puede llevar hasta el final. Esta es la parte que suele ser imposible de automatizar contra el sandbox de un proveedor, porque hace falta que un humano haga clic en algo.
Métodos que sacan al pagador de tu sitio
Las billeteras, las redirecciones bancarias y los métodos locales mandan a quien paga a otro lado y esperan a que vuelva. El backend también sirve esa página, y el pago queda en estado pendiente hasta que se aprueba o se cancela, exactamente como sería en producción. Los proveedores con página de checkout alojada funcionan igual: creas la sesión, obtienes una URL, y terminarla liquida el pago.
Claves de idempotencia
Manda la misma clave de idempotencia dos veces y recibes el primer resultado en lugar de un segundo cobro, en los proveedores que lo soportan. Es uno de los comportamientos más difíciles de probar en otro lado, porque necesita un proveedor que de verdad recuerde tu clave.
Qué vuelve
Los cuerpos de las respuestas, los nombres de los campos y los códigos de estado HTTP son los del PSP. Una librería cliente escrita para el proveedor funciona sin cambios, que es justamente la idea: cambias una URL base y nada más.
Cada pago lleva su propia historia, así que sus capturas y sus reembolsos son parte de él y no registros sueltos que haya que coser. Los puedes recorrer en la app por referencia, monto, estado, método o pagador.
Consulta Actividad del backend.
Decidir qué pasa
No estás esperando a ver qué se le ocurre al backend. Nombra al titular de la tarjeta, al correo de quien paga o al monto según el resultado que quieras, y eso es lo que vuelve, en el código de rechazo del propio proveedor.
Consulta Escenarios de pago.
Dónde responde
Cada versión de un proveedor responde bajo su propia ruta, que lleva la marca, la API y la versión. En un backend alojado, esa ruta está en el propio host del backend:
https://<hostname>.pay.mockz.io/adyen/checkout/v71/paymentsTodo lo que va después de esa ruta es la ruta propia del proveedor. Un backend puede servir varios proveedores a la vez, cada uno bajo su propia ruta.
Consulta Crear un backend alojado.