Probar en sandbox sin gastar créditos
Sandbox es un modo por aplicación en el que cada proveedor está simulado, no se factura nada y puedes forzar cualquier resultado de verificación que necesites - aprobada, rechazada o en revisión.
Sandbox es un modo de una aplicación, no un interruptor dentro de tu aplicación en producción. Crea una segunda aplicación en modo sandbox, usa su clave de API y cada comprobación queda simulada, no se factura nada y puedes forzar el resultado que quieras. Si solo ves una aplicación de producción, necesitas crear la de sandbox: el modo se elige por aplicación.
El sandbox de Didit es el equivalente a las tarjetas de prueba de un proveedor de pagos: te permite reproducir cualquier resultado de verificación bajo demanda, sin llamar a proveedores reales, sin manejar datos personales reales y sin tocar tu saldo.
#Sandbox es un modo de una aplicación
Esta es la parte que confunde a la mayoría de la gente. Producción y sandbox son aplicaciones separadas dentro de la misma organización, así que el tráfico de prueba y los datos de producción nunca se mezclan. Cada aplicación tiene un modo, live o sandbox.
- Una clave pertenece a una aplicación: la clave de la aplicación sandbox no puede tocar sesiones en producción.
- Crea una clave separada para las pruebas en lugar de reutilizar la de producción.
- Crea una segunda aplicación
En la consola, abre el selector de aplicaciones de arriba y crea una aplicación nueva. Elige sandbox como su modo.
- Usa la clave de API de esa aplicación
Coge la clave de API en API y webhooks mientras la aplicación sandbox esté seleccionada. No existe una "clave de prueba" separada en una aplicación de producción: la clave es el entorno.
- Crea un flujo de trabajo en ella
Las aplicaciones sandbox tienen sus propios flujos de trabajo. Reconstruye (o copia) el flujo que quieras probar.
- Crea sesiones con normalidad
Mismo endpoint, mismo flujo de código. La única diferencia es qué clave envías.
Si tu consola solo muestra una aplicación de producción y no hay forma de añadir una de sandbox, pide a soporte que active la creación de aplicaciones sandbox para tu organización: es un ajuste a nivel de cuenta, no algo que hayas configurado mal.
#Qué cambia sandbox, y qué no
| Sandbox | Producción | |
|---|---|---|
| Proveedores externos | Todos simulados: nunca se llama a ningún tercero | Reales |
| Facturación | Nunca se factura; se omite la comprobación de saldo | Se factura por función completada |
| Límite de creación de sesiones | 500 cada 24 horas, por aplicación | Tu saldo |
| Carga útil del webhook | "environment": "sandbox" | "environment": "live" |
| Datos extraídos y estado | Simulados por el escenario que elijas | Derivados de la captura real |
| Medios capturados | Se almacenan de verdad, exactamente igual que en una sesión real | Se almacenan |
Sandbox almacena los medios que captura: documentos, selfie, vídeo de prueba de vida, archivos de comprobante de domicilio, exactamente igual que lo haría una sesión real. El resultado está simulado, pero la subida es real, así que usa los documentos de muestra y los datos de prueba que ofrece el flujo en lugar de un documento de identidad real o información personal real.
Como los resultados nunca dependen de los píxeles, una foto deliberadamente mala no producirá un rechazo en sandbox. El escenario es quien decide.
#Elegir el resultado
Pasa un slug de escenario como sandbox_scenario al crear la sesión, o deja que la persona que prueba elija uno: las sesiones de sandbox en el flujo alojado muestran un selector de escenario dentro de la tarjeta antes de que empiece la captura, además de una franja de documentos de muestra bajo el componente de subida y un aviso permanente de "solo datos de prueba".
Los escenarios cubren los resultados que realmente necesitas para probar tu integración:
| Quieres probar | Escenario |
|---|---|
| Todo se aprueba | approve |
| Documento caducado | decline_document_expired |
| Documento ilegible | decline_could_not_recognize_document |
| Fallo de suma de comprobación del MRZ | decline_mrz_validation |
| Por debajo de la edad mínima | decline_minimum_age |
| Coincidencia facial demasiado baja | decline_face_match_low_similarity |
| Ataque de suplantación en la prueba de vida | decline_liveness_attack |
| Coincidencia con sanciones / PEP en AML | decline_aml_hit |
| Dirección IP bloqueada | decline_ip_blocklist |
| Discrepancia de dirección en el comprobante de domicilio | decline_poa_address_mismatch |
| Fallo de integridad del chip NFC | decline_nfc_chip_not_verified |
| La validación de base de datos no encuentra nada | decline_database_no_match |
| Necesita revisión manual (AML) | review_aml_possible_match |
| Necesita revisión manual (coincidencia facial límite) | review_face_match_borderline |
| Necesita revisión manual (coincidencia parcial de dirección) | review_poa_partial_match |
| Discrepancia con el registro en KYB | decline_kyb_registry_mismatch |
Los escenarios review_* existen para que puedas ejercitar todo el flujo de revisión manual (la cola de revisión de la consola, el webhook de In Review, un revisor aprobando o pidiendo un reenvío) sin necesitar una entrada que provoque un rechazo.
El catálogo en vivo de escenarios y valores mágicos lo sirve la propia API en
GET /v1/sandbox/scenarios/. Si algún slug de aquí llega a quedar desactualizado,
confía en el endpoint. Referencia completa: pruebas en sandbox.
#Distinguir los dos entornos en tu propio código
Cada webhook lleva un campo environment: "sandbox" o "live". Actúa según eso en lugar de intentar deducir el entorno a partir de la clave, y nunca confundirás una sesión de prueba con un cliente real.
#Lo que sandbox no hará
- No devolverá datos de registro reales de una empresa real. El KYB de sandbox usa respuestas de registro simuladas.
- No enviará un SMS ni un correo real. La verificación de teléfono y correo electrónico están simuladas, así que no puedes usar sandbox para comprobar la entregabilidad real de los mensajes.
- No consumirá tus asignaciones mensuales gratuitas, lo que también significa que una ejecución en sandbox no te dice nada sobre las comprobaciones gratis que te quedan.
#Si necesitas verificaciones de prueba reales
Algunas cosas requieren genuinamente una llamada real: comprobar que el servicio de base de datos de un país concreto está aprovisionado para ti, o confirmar la entrega de un SMS a un operador concreto. Eso necesita una pequeña recarga en una aplicación de producción en lugar de sandbox. Pregunta a soporte antes de gastar en ello, para que puedan confirmar primero que el servicio está realmente activado en tu cuenta.