Escenarios de identidad
Tú decides cómo termina una verificación nombrando a la persona o a la empresa según el resultado que quieras.
Llama sanctions_match al solicitante y el caso vuelve rechazado, con el impacto en la revisión de listas y no en la de documentos. Llámalo approve y pasa todo.
Nombra al sujeto
El nombre se revisa primero, sin distinguir mayúsculas, y coincide entero o por su última palabra. Así que funcionan tanto sanctions_match como Jane sanctions_match, lo que importa cuando un formulario exige un nombre de pila.
Usa approve para un paso limpio, o cualquiera de estos rechazos:
- Documentos:
document_expired,document_not_supported,document_unreadable,document_tampered,document_type_mismatch - Rostro y prueba de vida:
face_mismatch,face_not_detected,liveness_failed - Cruce con listas:
sanctions_match,pep_match,adverse_media_match,watchlist_match - Datos declarados:
data_mismatch,identity_not_found,address_not_verified,phone_not_verified,email_not_verified,underage - Empresas:
business_not_found,business_inactive,ownership_not_verified,tax_id_mismatch - Riesgo:
device_risk,blocklisted,duplicate_subject
Cada rechazo aterriza en la revisión que le corresponde. Pedir una revisión de documento y una de listas sobre un solicitante llamado pep_match te da un informe de documento limpio y un rechazo en la de listas, que es la forma que tu código de parseo tiene que manejar igual en producción.
Resultados que no son pasar ni fallar
Tres nombres producen los estados más difíciles de reproducir en cualquier otro lado:
reviewdevuelve un caso que se supone que mire una persona. Todas las revisiones corren, y la que nombra vuelve no concluyente en lugar de fallida.pendingdevuelve un caso que todavía no responde. Sigue corriendo hasta que se lo vuelva a leer o se lo reanude, que es contra lo que se escribe una integración que consulta.hosteddevuelve un caso esperando a que el sujeto complete la captura por su cuenta. Sigue el enlace de la respuesta y termínalo ahí.
Un proveedor sin flujo alojado aprueba hosted en su lugar, así que el mismo test igual corre.
Sujetos a los que no nombraste
Una captura alojada, un flujo de SDK o un sujeto importado llegan con un nombre que no elegiste. Otros cuatro disparadores llegan a esos:
- El correo
declined@example.com,sanctioned@example.com,review@example.comopending@example.com. - La fecha de nacimiento
2015-01-01, para alguien demasiado joven para pasar. - El país
KP, para un sujeto que declara un país sancionado. Escríbelo con dos letras, tres letras o el código numérico: los tres llegan al mismo disparador, sea cual sea la forma que registre el proveedor. - Tu propia referencia, donde el proveedor acepte una.
Los datos de prueba del propio proveedor
Cada proveedor conserva los valores de su propia documentación. Los nombres de solicitante clear y consider de Onfido funcionan, junto con los números de documento que publica su sandbox. Persona responde a pass y fail, y a referencias como test-declined.
Qué disparador gana
Un caso toma el primer disparador que coincide, en este orden:
- Nombre, entero o por su última palabra
- Correo
- Tu propia referencia
- Número de documento
- Fecha de nacimiento
- País
- Tipo de revisión
Ver a qué responde un proveedor
Abre el backend, ve a Escenarios y elige un proveedor.
De fábrica es el conjunto propio de ese proveedor.
Compartido es la base a la que responde cada proveedor, que es la lista del principio de esta página.
Las dos son de solo lectura, y las dos están ahí para copiar de ellas.
Cuando la lista incluida no alcanza
Escribe la tuya. Los tuyos se prueban antes que cualquiera de fábrica.
Consulta Escribe tus propios escenarios.