¿Qué debe aceptar antes de habilitar un piloto de verificación?

El problema: un fixture en verde no es un piloto

El atajo tentador es ejecutar el ejemplo sintético, ver el estado approved y solicitar un piloto como si la integración estuviera probada. El fixture solo acepta callbacks sintéticos: los ID de evento deben empezar por fixture-, el origen debe ser fixture_callback y el modo synthetic_fixture. Cualquier otro modo u origen lanza PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. No tiene un verificador real de firmas. Su paso recover hace expirar la sesión localmente y nunca consulta a un proveedor. Un permiso concedido en el fixture es un registro local; todas las salidas indican live_permission_changed false. Por tanto, la pregunta para el lector es: ¿qué comportamientos propios del llamador ha probado y cuáles aún necesitan evidencia real?

Escenario HIPOTÉTICO y salidas esperadas

Hipotéticamente, un equipo que incorpora vendedores ejecuta localmente el ejemplo descargable de cuatro ramas. Este ejemplo es distinto de la prueba HTTP anónima de tres escenarios. Al crear la sesión debe devolver mode synthetic_fixture, state simulated, session fixture-session, link_executable false y next send_real_provider_link_only_after_authorization. Un evento fixture-approved con policy true debe devolver status approved, deadline 60, permission_granted true y grant_count 1. Repetir el mismo evento debe devolver un registro idéntico, con grant_count todavía en 1. Una corrección posterior a Declined debe devolver status declined con permission_granted false y grant_count 1. En otra ejecución en la que la sesión sigue pendiente tras el plazo, recover debe devolver 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 debe lanzar BINDING_MISMATCH, y la lectura de una sesión desconocida debe lanzar SESSION_NOT_FOUND.

Manejo de fallos que su aplicación debe asumir

Diseño propuesto: trate unknown, review y expired como estados que no conceden permiso y que se dirigen a revisión humana o a una actualización autorizada del proveedor. Nunca los trate como aprobaciones o rechazos silenciosos. Vincule cada evento al tenant y al sujeto. Elimine duplicados por sesión y evento antes de conceder nada. Haga que una corrección a Declined revoque la concesión local. Tras una interrupción, lea el registro existente en lugar de crear una sesión nueva, y use un UUID de idempotencia por solicitud. Si el registro incluye una comprobación telefónica, las ramas unknown y provider_failure del fixture devuelven valid null. Diríjalas a review_or_existing_otp o a bounded_retry_then_review; ninguna envía OTP.

Lo que GridZen ha validado realmente

Según la guía, una comprobación telefónica básica real funcionó a través de la API desplegada y de MCP. Una sesión de identidad de operador aprobada previamente se actualizó y se leyó mediante las interfaces de cliente. En la identidad alojada están evidenciados la creación real, las notificaciones firmadas, las lecturas autoritativas y la expiración. Sigue sin validarse lo siguiente: que un humano complete una sesión nueva, el webhook final real de un usuario recién aprobado y una acción de negocio de extremo a extremo del cliente. Las pruebas del operador no son demanda de clientes. Approved nunca es un permiso incondicional; deciden sus reglas.

Condiciones del piloto que debe comprobar, no suponer

Una cuenta de comerciante verificada puede enviar una solicitud de piloto. El responsable revisa el propósito, los acuerdos posteriores, los derechos del proveedor, las capacidades, la asignación gratuita y la expiración. Las solicitudes nunca habilitan producción automáticamente. La prueba actual de identidad alojada para empresas elegibles de EE. UU. y Reino Unido es limitada: 2 solicitudes por dominio empresarial verificado y 10 solicitudes compartidas de por vida, con aceptación aparte del anexo de Didit. Cubre solo módulos gratuitos confirmados, y los pagos de clientes están desactivados. La verificación de cuentas bancarias, KYB y la aprobación automática de empresas no están disponibles. Las asignaciones gratuitas no conceden derechos de reventa ni garantizan condiciones futuras.

Lista práctica de aceptación

Antes de solicitar, confirme cada punto. 1) Las siete salidas del fixture indicadas coinciden exactamente, incluidos los dos códigos de error. 2) Su manejador rechaza concesiones sin una política explícita y sin vinculación de cuenta. 3) Los eventos duplicados no incrementan grant_count. 4) Declined revoca el acceso. 5) Los estados expired, unknown y review llegan a una cola de revisión. 6) La recuperación lee registros existentes y nunca duplica sesiones. 7) Ha leído las capacidades y ha documentado su propósito y sus acuerdos posteriores. 8) Ha registrado la evidencia que falta: un webhook final firmado real, un usuario recién aprobado y una acción de negocio en vivo. Verifíquelas durante el piloto limitado antes de depender de ellas. Su siguiente paso es ejecutar el ejemplo sintético e inspeccionar su manejo de fallos. Solicite un sandbox guardado solo si la tarea encaja.

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/customer-pilot/ 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.