Modo prueba
Cada comercio tiene dos juegos de llaves: sk_test_… / pk_test_… y sk_live_… / pk_live_…. El sufijo decide a dónde va el cobro.
Un cobro en modo prueba no es una simulación nuestra: viaja al ambiente de pruebas del propio banco. Recibes sus respuestas y sus códigos de error reales, así que lo que programes contra el modo prueba es lo que va a ocurrir en producción — no una imitación que puede desviarse.
En modo prueba no se mueve dinero y no se factura. Las transacciones aparecen en tu dashboard marcadas como PRUEBA, y quedan fuera de tu consumo y de tu analítica.
Qué necesitas para empezar
Pídenos que activemos el modo prueba en tu pasarela. Lo encendemos por comercio y por pasarela: mientras integras está encendido, y lo apagamos cuando sales a producción.
Del banco no necesitas nada: no hace falta que te haya entregado tus credenciales todavía. Puedes integrar mientras ese trámite avanza y cambiar a producción cuando lleguen.
Cuando las tengas, las cargas tú mismo desde el dashboard. A partir de ahí tus llaves live empiezan a cobrar de verdad.
Con el modo prueba apagado, una llave de prueba recibe 409 al crear la sesión
(POST /v1/sessions) o al cobrar una tarjeta guardada (POST /v1/charges). El
mensaje dice qué hacer: en producción, usa tu sk_live_….
Qué pasarelas admiten cobros de prueba
Hoy solo Mercantil (API directa), que es la única que nos da un ambiente de pruebas al que apuntar.
En cualquier otra pasarela, un cobro con llave de prueba se rechaza con un mensaje claro, tanto en el checkout como en el cobro con tarjeta guardada. Preferimos decírtelo a mandarlo a producción con una llave de prueba —te cobraría de verdad— o a inventarte un resultado que no se parece al real.
Si tu pasarela no admite pruebas, usa el probador de webhooks de la sección siguiente: cubre lo que de verdad suele romperse.
Tarjetas de prueba
Las entrega el banco, no nosotros, y cambian de vez en cuando. Pídelas a tu contacto o escríbenos y te pasamos la lista vigente.
Una tarjeta de prueba con fecha vencida te va a dar 0120 (tarjeta vencida). Es la respuesta correcta: revisa que la lista que tienes esté al día.
Probar tus webhooks sin hacer un cobro
Lo que más suele fallar al integrar no es el cobro: es el manejo del evento que llega después. Por eso el probador manda eventos con la forma real, no un “hola, tu endpoint responde”.
Desde el dashboard, en tu endpoint de webhooks, elige el evento que quieres ensayar —charge.approved, charge.declined, session.expired…— y lo recibes con los mismos campos, los mismos nombres y los mismos nulos que tendría uno de verdad.
Funciona con cualquier pasarela, porque no depende de que haya un cobro detrás.
Todo evento de ejemplo trae data.sample: true y referencias obviamente falsas (txn_sample…). Si tu sistema despacha mercancía al recibir charge.approved, comprueba ese campo: un ejemplo no es un pago.
Pasar a producción
- Carga las credenciales de tu banco en el dashboard.
- Cambia
sk_test_…porsk_live_…en tu servidor ypk_test_…porpk_live_…en tu checkout. - Avísanos: apagamos tu modo prueba. Desde ese momento, si alguna parte de tu
servidor sigue usando la
sk_test, falla con un error en vez de aprobarse en el ambiente de pruebas. - Nada más. Los endpoints, los payloads y los eventos son idénticos.
Si ves cobros marcados PRUEBA en producción, tu servidor está creando las
sesiones (o cobrando tarjetas guardadas) con la sk_test: esos cobros se
aprobaron en el ambiente de pruebas del banco y no te van a llegar. Revisa
en el dashboard, en Claves de API, el último uso de cada llave: te dice
cuál está usando tu servidor.
Si usas una llave live sin haber cargado tus credenciales, el cobro falla con un error explícito. Nunca cae de vuelta a nuestro ambiente de pruebas: eso te haría creer que cobraste cuando no se movió nada.