Escenarios de pago
El sandbox de un proveedor decide qué hace tu pago. Acá decides tú, nombrando el pago según el resultado que quieras.
Llama insufficient_funds al titular de la tarjeta y el pago se rechaza por ese motivo, en el código del propio PSP. Llámalo approve y pasa, sea cual sea el número de tarjeta que mandaste.
Nombra al titular de la tarjeta
El nombre del titular es lo primero que se revisa, y se compara sin distinguir mayúsculas. Usa approve para una autorización limpia, o cualquiera de estos rechazos:
- Estado de la tarjeta:
expired_card,invalid_card,blocked_card,restricted_card,lost_card,stolen_card - Dinero:
insufficient_funds,withdrawal_amount_exceeded,invalid_amount - Fraude y verificaciones:
fraud,acquirer_fraud,issuer_suspected_fraud,avs_declined,cvc_declined - Rechazado o derivado:
declined,referral,transaction_not_permitted,not_supported,not_3ds_authenticated - Fallas del otro lado:
acquirer_error,issuer_unavailable
Cada proveedor responde a las mismas palabras y devuelve su propio código para ellas. Escribes el test una vez, y agregar un segundo PSP no significa aprender un segundo vocabulario.
Pagos que no llevan nombre
Las billeteras, las tarjetas guardadas y PayPal no tienen titular al que nombrar. Otros dos disparadores llegan a ellos:
- El correo de quien paga,
declined@example.compara un rechazo simple, onobalance@example.compara fondos insuficientes. - El monto
99, en la moneda que estés mandando, también para fondos insuficientes.
3D Secure
Cuatro nombres mandan un pago con tarjeta a la autenticación en lugar de autorizarlo directo:
require_3dsfrena en un desafío.require_3ds_frictionlesspasa la autenticación sin ningún desafío.require_3ds_fingerprintrecoge primero una huella del dispositivo, y después desafía.require_3ds_fingerprint_frictionlessrecoge la huella y después pasa.
Un proveedor que no ofrece 3D Secure los aprueba en lugar de fallar, así que el mismo test puede correr contra un PSP que no tiene ese flujo.
Consulta Resumen del backend de pagos para ver cómo es el desafío en sí.
Los datos de prueba del propio proveedor
Cada PSP conserva los valores de su propia documentación por encima del conjunto compartido. Los nombres de titular DECLINED, REFERRAL y CARD_EXPIRED de Adyen funcionan, y también sus números de tarjeta de prueba y sus prefijos BIN publicados. Si tu equipo ya tiene una página con tarjetas de prueba del proveedor, siguen funcionando acá.
Qué disparador gana
Un pago toma el primer disparador que coincide, en este orden:
- Nombre del titular
- Correo de quien paga
- Número de tarjeta
- Monto
- Prefijo BIN de la tarjeta
- Método de pago
Ese orden es lo que vuelve útil a un nombre. Un nombre le gana a un número de tarjeta, así que nombrar approve al titular hace pasar una tarjeta que si no sería rechazada, y nombrarlo stolen_card rechaza una tarjeta que si no pasaría sin problema.
Ver a qué responde un proveedor
No hace falta que dejes esta página abierta para saber qué va a hacer un backend. Abre el backend, ve a Escenarios, y elige un proveedor.
De fábrica es lo que trae ese proveedor, incluidas sus propias tarjetas de prueba y sus nombres reservados.
Compartido es la base a la que responde cada proveedor en cada backend, que es la lista del principio de esta página.
Las dos son de solo lectura. Están ahí para leerlas y copiar de ellas.
Cuando la lista incluida no alcanza
Escribe la tuya. Un escenario dice qué solicitudes coincide y qué debería volver, y los tuyos se prueban antes que cualquiera de fábrica.
Consulta Escribe tus propios escenarios.