¿Cuándo es más sencilla la integración directa de verificación?

La decisión en un escenario hipotético

Hipotético: un equipo de dos desarrolladores gestiona un marketplace en un solo país. Incorpora a unos pocos vendedores por semana y necesita exactamente un evento de verificación: una comprobación de identidad alojada antes de que un vendedor pueda publicar artículos. El equipo ya tiene una cuenta con un proveedor y ha leído la documentación de webhooks del proveedor. No se planean comprobaciones telefónicas, riesgo de IP ni cotejo para pagos. Consejo: para un equipo así, la integración directa suele ser más sencilla. Hay un proveedor, un evento y un endpoint de callback, y no hay nada que normalizar entre proveedores. Una capa de orquestación se justifica cuando el equipo espera varios proveedores o eventos, necesita evidencia normalizada entre ellos, o quiere que las listas de rutas permitidas y la auditoría se gestionen fuera de su propio código. Ninguna de las dos vías elimina el trabajo descrito en las secciones siguientes. La integración directa solo cambia quién escribe ese trabajo.

Hechos del producto frente a consejos

Hechos de la guía: con BYOP, el cliente conserva su propia relación con el proveedor y autoriza un alcance de integración definido. GridZen usa un adaptador y una ruta aprobados para normalizar la evidencia. La alfa actual no acepta claves arbitrarias de proveedor en un navegador ni en el cuerpo de una petición. Una API pública o una cuenta disponible no es evidencia de permiso para vender los datos resultantes. Cada nuevo producto de proveedor necesita su propio adaptador y su propia revisión de alcance. El despliegue del piloto controlado tiene autorización de cuenta, listas de rutas permitidas, auditoría cifrada y limitación de tasa, pero eso no establece una preparación general para producción. Hechos de las notas de capacidades: las empresas elegibles de EE. UU. y Reino Unido pueden inscribirse por su cuenta en una prueba real de identidad alojada. La prueba permite 2 solicitudes por dominio empresarial verificado y 10 solicitudes compartidas de por vida, y requiere aceptar por separado el anexo de Didit. Están evidenciadas la creación real de sesiones, las notificaciones firmadas, las lecturas autoritativas y la expiración. Siguen sin verificarse un usuario recién Approved y la acción de negocio propia del cliente tras la aprobación. Los pagos de clientes están desactivados. Todo lo demás en este artículo es consejo.

Qué le corresponde si integra directamente

Consejo: con una integración directa, su código se encarga de todo lo siguiente: - Verificar las firmas de producción en los callbacks del proveedor. - Deduplicar eventos repetidos. - Vincular cada sesión al tenant y al sujeto correctos. - Gestionar correcciones, como un Approved seguido después de un Declined. - Hacer expirar las sesiones que nunca se completan. - Mantener el resultado de la verificación separado del permiso de negocio. La lista de preparación de la guía se aplica en ambos casos. Registre el producto del proveedor, el país, el evento, los identificadores permitidos, el titular de la cuenta, el manejo de credenciales y el alcance de la evidencia posterior. Confirme si está permitido el procesamiento en el servidor en nombre del cliente. Apruebe la retención, el borrado, el registro de accesos, la responsabilidad de la política y la recuperación operativa antes de cualquier uso real.

Ensaye el manejo de fallos con el fixture sintético

El fixture descargable tiene dos partes. La parte de identidad, Identity, guarda el estado del fixture en SQLite. El ejemplo telefónico de cuatro ramas es una parte separada. Ninguna de las dos es un adaptador real ni la prueba HTTP anónima. Su flujo de identidad produce estas salidas probadas: - create devuelve state "simulated", session "fixture-session", hosted_link en example.invalid, link_executable false y next "send_real_provider_link_only_after_authorization". - La aprobación con policy=True devuelve status "approved", deadline 60, permission_granted true, grant_count 1 y live_permission_changed false. - Repetir el mismo evento devuelve el registro idéntico, con grant_count todavía en 1. - Una corrección Declined devuelve status "declined" y permission_granted false, mientras grant_count sigue en 1. - En una sesión pendiente nueva, recover con now=61 devuelve status "expired", permission_granted false, grant_count 0, next "review_or_authorized_provider_refresh" y provider_polled false. - Un evento para una sesión desconocida lanza BINDING_MISMATCH. Leer una sesión desconocida lanza SESSION_NOT_FOUND. Use estas salidas como la especificación que su integración directa debe reproducir.

Límites del fixture

Comportamiento implementado: - El fixture solo acepta callbacks sintéticos: mode "synthetic_fixture", source "fixture_callback" e identificadores de evento con el prefijo "fixture-". - Cualquier otro mode o source lanza PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. No verifica firmas reales. - recover hace expirar las sesiones localmente y nunca consulta a un proveedor. - permission_granted es un indicador local del fixture. No es un permiso de negocio real, y live_permission_changed siempre es false. Su integración directa debe aportar por sí misma el verificador real de firmas y la nueva consulta autoritativa de la decisión del proveedor.

Lista de aceptación

- El registro de alcance está completo y se ha confirmado que el procesamiento en el servidor está permitido. - Las firmas de los callbacks se verifican con el mecanismo real del proveedor, y una firma ausente o inválida provoca el rechazo. - Un evento duplicado deja grant_count sin cambios. - Una discrepancia de tenant o de sujeto se rechaza. - Una corrección Declined revoca el permiso. - Un evento tardío después del plazo no puede conceder permiso. - La expiración envía la sesión a revisión o a una actualización autorizada con el proveedor. - Approved por sí solo nunca concede permiso; también se requiere una decisión explícita de política. - Las trazas no contienen identificadores sin procesar. - Hay responsables designados para la retención, el borrado y la recuperación. Si a su equipo le resulta fácil hacerse cargo de cada punto, la integración directa probablemente sea la opción más sencilla. Si varios puntos se repiten de un proveedor a otro, evalúe a continuación una ruta BYOP en sandbox.

Ejecutar el ejemplo sintético comprobado

Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

Fuentes y alcance

https://gridzen.ai/guides/bring-your-own-provider/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.