Test helper

Test helper: resolver una domiciliación pendiente

Los valores de prueba eligen el desenlace antes de empezar. El helper hace lo contrario: cambia la respuesta con el checkout ya en curso.

El caso típico: un pagador con la cédula 00000005 no logra validar su cuenta. Cada vez que pulsa "Ya la aprobé", el checkout le dice que la validación fue rechazada y lo devuelve a la pantalla de "apruébala en tu banca en línea", exactamente como a un cliente real cuyo banco todavía no aprueba la domiciliación. Llamas al helper y, desde el siguiente intento, la domiciliación queda aprobada y el checkout continúa como si el banco hubiera dicho que sí.

Es lo que te permite escribir una prueba automatizada del flujo completo de espera sin depender de un reloj.

La llamada

curl -X POST "https://api.venflow.app/v1/test_helpers/checkout/sessions/SESSION_ID/mandate" \
  -H "Api-Key: pvtk_9b1c..." \
  -H "Organization: org_xyz789..." \
  -H "Content-Type: application/json" \
  -d '{"resolution": "approve"}'

{
  "object": "test_helper.mandate_resolution",
  "session": "550e8400-e29b-41d4-a716-446655440000",
  "customer": "550e8400-e29b-41d4-a716-446655440001",
  "resolution": "approve",
  "livemode": false
}

La referencia completa del endpoint está en Resolver una domiciliación pendiente.

Cómo usarlo en una prueba

1. Crea la sesión con doc_id: "00000005".
2. Lleva el checkout hasta que la validación sea rechazada y el pagador vuelva a la pantalla de "apruébala en tu banca en línea" (el pagador ya se identificó).
3. Llama al helper con approve.
4. Pulsa "Ya la aprobé": la validación pasa y la suscripción se activa.

El paso 2 no es opcional: el helper resuelve a un pagador, y hasta que el pagador no se identifica en el checkout no hay a quién resolver.

Detalles que conviene tener claros

• Resuelve, no re-decide. Solo tiene efecto sobre un pagador que está esperando: cédulas 00000004, 00000005 y 00000007. A un pagador ya aprobado o ya rechazado no lo cambia, y tampoco a 00000006: el banco ya dio su respuesta, aunque sea inservible.
• Solo domiciliaciones. Un débito inmediato o un pago con tarjeta no tienen una domiciliación que aprobar; el helper no interviene en ellos. Sus desenlaces los eligen la cédula, el código OTP y el número de la tarjeta, de una vez.
• Va por pagador, no por organización. La respuesta se aplica al cliente de esa sesión y a nadie más, así que puedes tener varios checkouts vivos en el mismo sandbox sin que se pisen.
• Dura 24 horas y luego se olvida sola. Pasado ese plazo, el pagador vuelve a comportarse como dice su cédula — incluso en las renovaciones de una suscripción que ya habías activado con el helper.
• Alcanza también al cobro de la suscripción, no solo a la validación de la domiciliación: una vez aprobado, el checkout completa entero.
• Nace en el checkout, pero no se queda ahí. Lo llamas sobre una sesión, y mientras dura también alcanza a los cobros y reintentos posteriores de ese mismo pagador. Pasadas las 24 horas, para esos cobros manda la cédula.

Qué pasa si lo llamas mal

El helper falla cerrado, con mensajes que dicen qué corregir:

Ninguno de esos casos cambia nada. En particular, con una clave de producción el helper no puede tocar absolutamente nada: no es una puerta trasera a tus datos reales.