Lee el grado de verificación antes de decidir un cambio de beneficiario
Un vendedor pide cambiar la cuenta que recibe sus pagos. Tu servicio envía una CURP y una CLABE autorizadas para un cotejo de identidad y cuenta beneficiaria y recibe una respuesta. La decisión es si esa respuesta permite el cambio. Este artículo propone leer juntos el grado de verificación, el estado de la tarea, la evidencia y los cargos, con un ejemplo sintético de contrato cuya salida es status review, grade null, verified false y automatic_business_approval false. No es una verificación en vivo ni otorga permiso de negocio.
gridzen tools --product mx-identity-accountEl problema: un cambio de beneficiario depende de una respuesta
Un vendedor de un marketplace en México solicita una nueva CLABE de pago. El atajo riesgoso es tratar cualquier respuesta sin error como aprobación y cambiar la cuenta. El cotejo devuelve varias cosas separadas: un grado de verificación, un estado de tarea, evidencia y cargos. Los grados admitidos y las acciones requeridas siguen la cotización vigente, no una lista fija en tu código. Tu decisión es más estrecha de lo que parece: ¿este resultado concreto, bajo esta cotización aceptada, respalda cambiar este beneficiario, o la solicitud debe esperar revisión? El producto no da aprobación incondicional, no busca personas arbitrarias y no afirma un vínculo directo de identificador entre un banco y una CURP.
Qué significan las entradas y salidas
Las entradas son una CURP y una CLABE autorizadas, la cotización vigente, la evidencia y los consentimientos requeridos, y un UUID de solicitud estable. El UUID permite que un reintento se refiera a la misma solicitud en lugar de crear un segundo cotejo. La salida incluye grado, estado de tarea, evidencia y cargos. Léelos como señales distintas. El estado indica dónde está la tarea. El grado indica qué concluyó el cotejo, si concluyó algo. La evidencia indica qué respalda esa conclusión. Los cargos indican lo facturado según la cotización. Un grado nulo es ausencia de conclusión, que no equivale a un conflicto entre persona y cuenta. Los números de tarjeta no son entrada admitida, y no ocurre ninguna transferencia salvo que la cotización la autorice explícitamente.
Escenario hipotético y salida esperada del fixture
Hipotéticamente, un vendedor registrado envía una nueva CLABE. Tu servicio de onboarding manda la CURP y la CLABE autorizadas con la cotización aceptada y un UUID de solicitud nuevo. El ejemplo sintético de contrato devuelve exactamente estos campos: status review, grade null, verified false, automatic_business_approval false. El manejo esperado es: mantener activa la cuenta de pago actual, registrar la nueva CLABE como cambio pendiente, adjuntar el UUID y enviar el caso a tu propia cola de revisión. No muestres un rechazo al vendedor, porque nada se concluyó en su contra. No cambies la cuenta, porque verified es false y automatic_business_approval es false. Esta salida es una ilustración de contrato producida sin ninguna solicitud a un proveedor; no es evidencia de una verificación en vivo ni de un cliente.
Diseño propuesto frente a comportamiento implementado
Comportamiento implementado, según la documentación: el cotejo acepta las entradas indicadas y reporta grado, estado, evidencia y cargos, con grados y acciones regidos por la cotización vigente y las capacidades actuales. La ejecución del comercio requiere capacidades actuales, autorización y la cotización aceptada. Diseño propuesto, que construyes tú: una tabla de decisión que asigna estado y grado a una acción interna. Por ejemplo, review o un grado nulo se traducen en espera; un grado admitido con evidencia pasa a tu propia comprobación de política antes de cualquier cambio. Ni siquiera un grado positivo activa automatic_business_approval en tu sistema; tu regla, registrada por separado, decide si cambia el beneficiario.
Manejo de fallos
Si la llamada falla técnicamente, conserva el beneficiario anterior y reintenta con el mismo UUID de solicitud, no con uno nuevo, para no pagar ni registrar dos cotejos. Si la cotización expiró o cambió, obtén una cotización vigente antes de reenviar; no reutilices condiciones obsoletas. Si falta evidencia o consentimiento requerido, detente y recógelo en lugar de enviar. Si aparece un grado que tu tabla no reconoce, trátalo como espera y revisa las capacidades actuales, ya que los grados admitidos siguen la cotización vigente. Registra los cargos tal como aparecen en la salida en lugar de suponer un monto fijo.
Lista de aceptación
Antes de habilitar cambios de beneficiario con este resultado: la salida del fixture status review, grade null, verified false, automatic_business_approval false produce una espera, no un rechazo ni un cambio; los reintentos reutilizan el UUID estable; la cotización usada está vigente y aceptada; CURP y CLABE están autorizadas y los consentimientos guardados; no se envía ningún dato de tarjeta; no hay transferencia sin autorización explícita de la cotización; los grados desconocidos quedan en espera; los cargos se registran desde la salida; y el cambio final lo hace tu propia regla registrada. Superar el ejemplo sintético demuestra tu lógica de manejo, no un permiso de negocio real ni cobertura del proveedor.
Revisar este producto
https://gridzen.ai/tools/mx-identity-account/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.
gridzen tools --product mx-identity-accountFuentes y alcance
https://gridzen.ai/tools/mx-identity-account/ 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.