Valores de prueba

Valores de prueba

En el sandbox, lo que escribe el pagador decide qué responde el banco simulado. Es la misma idea que las tarjetas de prueba de otras pasarelas: escribes un valor reservado en el checkout y obtienes el desenlace que quieres ensayar.

Hay tres tablas, una por medio de pago, y las tres se leen igual: cualquier otro valor se comporta como un pagador normal y aprueba. No necesitas saberte ninguna para que tu primer checkout funcione.

Códigos MOCK_

Todo rechazo del banco simulado trae un código con el prefijo MOCK_ (por ejemplo MOCK_AC04 para una cuenta cerrada, MOCK_05 para una tarjeta no honrada). Imitan el vocabulario de un banco real para que el fallo se parezca al de verdad, pero el prefijo está ahí a propósito: un código del sandbox nunca debe poder confundirse con la respuesta de un banco en tus registros. No escribas comparaciones exactas contra ellos en el código que va a producción.

Lo mismo con las referencias: toda referencia bancaria que emite el banco simulado empieza por MOCK-.

Dónde los ves

Cuando lo que falla es la validación de la cuenta en un checkout de domiciliación (ver abajo), ten en cuenta dos cosas al consultar el API:

• La sesión sigue en in_progress. El pagador todavía puede corregir y reintentar mientras la sesión esté vigente, así que el rechazo no la cierra.
• No se crea ningún pago. El cobro de validación de 1 Bs no es un pago de la suscripción: el pago y la factura existen solo cuando la validación pasa. Por eso el código MOCK_ de ese rechazo solo te llega por el webhook.

Domiciliación: la cédula

Aplica a los planes recurrentes. El banco simulado responde según la cédula del pagador en dos momentos:

1. En el checkout, al validar la cuenta. Antes de activar la suscripción, el checkout le cobra al pagador 1 Bs y se lo devuelve, para comprobar que la domiciliación funciona. La cédula actúa desde este cobro, así que es lo primero que vas a ver.
2. En los cobros de la suscripción: el primero y cada renovación, una vez que la suscripción está activa.

Algunas cédulas se ven distinto en cada momento. La tabla dice qué responde el banco; la siguiente, qué ve el pagador en el checkout.

Da igual cómo escribas la cédula: V-00000002, v00000002 y 00000002 significan lo mismo. Solo cuentan los dígitos.

Qué ve el pagador en el checkout

Mientras se valida la cuenta, el pagador ve la pantalla "Confirmando con tu banco". Lo que pasa después depende de la cédula:

No son solo el primer cobro

El desenlace viaja con el pagador, no con la sesión. El cliente que creaste con 00000003 va a seguir rechazando en cada renovación de esa suscripción, que es justo lo que necesitas para ensayar tu cobranza automática.

Y como la elección es por pagador, puedes tener varios checkouts vivos en el mismo sandbox, cada uno con su desenlace, sin que se pisen. Una suite de pruebas puede correr en paralelo.

Combinaciones

Los valores de prueba conviven con el resto de las opciones del plan:

• Con período de prueba (trial): con 00000004, la validación tarda unos segundos más en confirmarse y la suscripción queda en trialing.
• Con inicio diferido: la domiciliación se resuelve igual; el primer cobro espera a su fecha.

Cuáles puede cambiar el test helper

El test helper cambia la respuesta con el checkout ya en curso, pero solo sobre una domiciliación que está esperando:

Si lo que buscas es un pagador que siempre falle, hagas lo que hagas, ese es 00000002: el helper no lo toca.

Débito inmediato: la cédula y el código OTP

Aplica al pago único (un plan de tipo one_time) y a los links de pago. El pagador escribe su cédula y su teléfono, pulsa Pagar, y el checkout le pide el código OTP que su banco le habría enviado por SMS.

En el sandbox no se envía ningún SMS. Cualquier código de ocho dígitos se acepta, salvo uno:

Con el código aceptado, la cédula del pagador elige el desenlace con la misma tabla de la domiciliación. Como aquí no hay una cuenta que domiciliar, dos de los valores significan algo ligeramente distinto:

El pagador lee el motivo del rechazo en el cuadro del código, con las mismas palabras que usaría un banco real ("Clave incorrecta", "Insufficient funds"). El código (MOCK_OTP, MOCK_AM04) no se muestra en pantalla: queda en la solicitud de pago, que ves en el panel con el modo sandbox encendido.

El test helper no interviene en el débito inmediato: solo resuelve domiciliaciones.

Tarjeta: el número

Aplica al pago único y a los links de pago, y solo si tu organización real tiene el pago con tarjeta habilitado: el sandbox ofrece exactamente los medios que tu organización tiene habilitados, sin importar con qué banco cobras.

El número de la tarjeta decide. Son los mismos números que publican otras pasarelas para las mismas cuatro situaciones, para que los reconozcas a la vista:

Cualquier otro número válido (entre 13 y 19 dígitos, que pase la verificación de dígito de control) se cobra como una tarjeta normal. Los demás campos no influyen: cualquier fecha de vencimiento futura, cualquier código de seguridad de tres dígitos, cualquier nombre.

Los cuatro números empiezan por 4, así que el formulario los lee como Visa y no pide PIN.

Lo que no se puede ensayar

Pago Móvil no está en el sandbox. Es un medio que se verifica contra el banco —Venflow busca el movimiento en la cuenta del comercio antes de dar el pago por bueno— y no hay banco contra el cual verificar. En producción está disponible para los comercios que cobran por BNC.

Eso tiene una consecuencia para tu conciliación: la referencia que un pago por Pago Móvil trae en bankReference (la que el pagador ve en su app) solo la vas a ver en producción. En el sandbox, toda referencia es MOCK-… y viene del débito inmediato, de la domiciliación o de la tarjeta. Si tu integración cruza referencias contra extractos, pruébala con los pagos que el sandbox sí produce y deja Pago Móvil para el cobro piloto.