Pruebas

Una clave de prueba no mueve dinero real, pero casi todo lo demás es real.

Las claves de prueba

Sus claves existen en dos familias: sk_live_… y sk_test_…. La clave utilizada marca la operación durante toda su vida; nada traslada una operación de una familia a la otra.

Con una clave de prueba:

• nunca se llama a ningún proveedor. Responde una simulación en su lugar, siempre — una ejecución de prueba no puede alcanzar un carril real ni perturbarlo.
• el libro mayor, las liquidaciones y las notificaciones transaccionales quedan excluidos. Ningún movimiento contable, ningún total de liquidación, ningún SMS ni correo al pagador.
• todo lo demás es real: la cadena de aceptación, sus webhooks, sus registros de desarrollador, sus filas de reporting y la totalidad de los controles de riesgo.

Importes mágicos

Los dos últimos dígitos del importe eligen el resultado. Es la única manera de ensayar las rutas de fallo, que un carril en buen estado nunca produce.

El importe termina en	Qué ocurre
99	Rechazado al enviar, de forma definitiva. La clase «número inválido» — no reintente
98	Rechazado al enviar, de forma temporal. La clase «caída del carril» — reintentar tiene sentido
97	Aceptado y luego fallido. Primero pending, después failed
cualquier otra cosa	Aceptado y luego success

Esto se aplica igualmente a cobros, pagos, reembolsos y anulaciones.

El caso 97 es el que de verdad conviene ensayar

Es la secuencia que las integraciones pasan por alto: su webhook recibe pending, usted marca el pedido como «pendiente de pago», y después llega failed y debe deshacer lo que hizo pending. Sin una forma de provocarla, la primera vez que se recorre esa ruta es en producción.

Un importe que ha codificado un fallo falla de principio a fin: una operación no puede a la vez rechazar y tener éxito, por muchas veces que la consulte.

Identidades de prueba

Los controles de cumplimiento se ensayan del mismo modo, con identidades mágicas. Solo coinciden con operaciones de prueba.

Identidad	Qué ensaya	Qué debería ver
+221700000001 — «Test Sanctionne Fort»	Coincidencia fuerte con una lista de sanciones	El pago se rechaza.
«Test Sanctionne Nom Seul» (solo nombre, sin número)	Coincidencia solo por el nombre	Aceptado y luego retenido para revisión — véase más abajo
+221700000003 — «Test Personne Politiquement Exposee»	Persona políticamente expuesta	Revisión reforzada, no un rechazo
+221700000004 — «Test Identite Mineure»	Identidad conocida como menor de edad	Rechazado en un corredor restringido (juego, apuestas), aceptado en el resto

Conjunto de identidades vigente: fixture-2026-09-13-1. Es idéntico en todos los entornos y cambia por versión — una prueba escrita contra un conjunto con nombre sigue siendo reproducible.

Un nombre por sí solo nunca es un rechazo

La segunda fila sorprende, y es deliberado: una coincidencia únicamente por el nombre no detiene un pago. Los apellidos se comparten; rechazar por el nombre significaría rechazar a muchísimas personas por escribirlo correctamente. Por eso el pago se acepta y queda retenido para revisión, y su integración debería tratarlo como una espera, no como un fallo.

Un rechazo requiere un identificador fuerte: un número, un documento.

⚠️ Estas identidades no son personas reales y nunca coinciden con un pago de producción. Usarlas con una clave sk_live_ no produce absolutamente nada: son identidades de ensayo y nada más.

Qué puede ensayar

• risk.status pasando a review y a held, tanto en el webhook como en una lectura;
• los eventos payment.held y payment.released;
• un expediente de cumplimiento abierto en la vía de prueba: visible para usted, y que nunca llega a nuestro equipo de cumplimiento ni a ningún total regulatorio.

Qué no muestra una ejecución de prueba

Tres límites, dichos con claridad en lugar de descubiertos más tarde:

1. Ningún movimiento contable. El libro mayor queda fuera del perímetro de prueba, por lo que nada relativo a un saldo disponible, una retención o una liberación de fondos puede verificarse aquí.
2. Los tiempos no son los de producción. La simulación no tiene pagador: la confirmación proviene de un barrido con su propia cadencia, no de unos segundos después de un código USSD. Pruebe la transición, nunca el reloj.
3. Las notificaciones transaccionales no se envían. Ni al pagador ni a usted.

Lo que no debe hacer

• No deduzca sus tiempos de producción a partir de sus tiempos de prueba. Véase el punto 2.
• No trate pending como un fallo, ni en pruebas ni en producción.
• Nunca copie una identidad de prueba en sus datos de producción. Allí no coincide con nada, y un dato de ensayo en un registro real es una pista falsa para quien lo lea después.