Recupera una solicitud de evidencia SPEI pendiente sin crear un duplicado
Tu proceso de conciliación envió una verificación de CEP para un pago SPEI existente y recibió el estado pending. Horas después la tarea sigue pendiente, un worker se reinició y alguien propone volver a enviar el mismo pago. Ese atajo puede crear una segunda tarea para una sola transferencia y dejar dos registros que no coinciden. Este artículo propone cómo una aplicación podría recuperar la tarea original, qué devuelve el ejemplo de contrato sintético y cómo mantener como no concluyentes los resultados pendientes o no disponibles.
gridzen tools --product mx-cepEl problema y la decisión
Una verificación de CEP responde a una pregunta acotada sobre un pago que ya existe: ¿se puede obtener la evidencia original, su firma es válida y se vincula exactamente con la operación descrita? No inicia una transferencia ni prueba el control actual de la cuenta, la identidad o que un pago saliente sea seguro. Las restricciones de acceso a la fuente pueden retrasar una tarea, así que pending es un estado normal, no un error. La decisión es qué hace tu proceso cuando una tarea sigue pendiente: reenviar, esperar o recuperar la tarea existente. Aquí defendemos la recuperación ligada a una tarea almacenada y tratar todo resultado no final como no concluyente.
Qué define el contrato del producto
Las entradas documentadas son fecha de operación, clave de rastreo, códigos de institución emisora y receptora, cuenta, monto y referencia de autorización. La salida informa estado de la tarea, disponibilidad de la evidencia original, estado de la firma y vinculación exacta con la operación. Las herramientas listadas son mexico_cep_capabilities, submit_mexico_cep_check, get_mexico_cep_check y recover_mexico_cep_check. La ejecución comercial requiere capacidades vigentes, autorización y una cotización aceptada. Todo lo que va más allá de esos hechos es un diseño de aplicación propuesto, no un comportamiento implementado del proveedor. El ejemplo es una ilustración sintética del contrato: no se realiza ninguna solicitud real y no es evidencia de una verificación en vivo ni de un cliente.
Diseño propuesto: un pago, una tarea almacenada
Antes de enviar, la aplicación podría construir una clave de deduplicación con las entradas exactas: fecha de operación, clave de rastreo, ambos códigos de institución, cuenta, monto y referencia de autorización. Guarda esa clave junto con el identificador de tarea en almacenamiento duradero, en el mismo paso que registra el envío. Cuando un worker se reinicia o vence un temporizador, el proceso busca primero la clave. Si existe una tarea, llama a get o recover para esa tarea en lugar de submit. Solo si no hay tarea almacenada y la autorización sigue vigente se justificaría un nuevo envío. Un monto o clave de rastreo distintos son otra operación y merecen una clave nueva, no una sobrescritura silenciosa.
Escenario hipotético y salida esperada del fixture
Hipotéticamente, un equipo de finanzas revisa una transferencia. El proceso envía, guarda la clave y la tarea, y el worker se reinicia. Al reanudar encuentra la tarea almacenada y la recupera en lugar de reenviar. El ejemplo de contrato sintético devuelve exactamente: status pending, original_available false, signature_status not_checked, transaction_binding not_checked, verified false. La lectura correcta es que aún no se ha establecido nada. El pedido no se libera, el registro mantiene una sola tarea y ningún campo se convierte en conclusión. Tu prueba debe afirmar literalmente estos cinco valores y que el número de tareas para la clave sigue siendo uno.
Manejo de fallos
Trata pending y no disponible como no concluyentes, nunca como fallo del pago ni como aprobación. Si original_available es false, no hay evidencia original que evaluar. Si signature_status o transaction_binding es not_checked, no infieras validez a partir de otros campos. Un retraso por restricciones de acceso a la fuente debe llevar a una espera acotada y a una recuperación posterior, registrada con marcas de tiempo, no a un envío duplicado. Si la autorización caducó o las capacidades ya no incluyen la ruta, detén el proceso y escala a una persona. Incluso un resultado verificado solo describe la evidencia de un pago existente; liberar pedidos depende de tus reglas de negocio, y el resultado no prueba quién controla hoy la cuenta.
Lista de aceptación
Antes de confiar en el proceso, confirma: la clave de deduplicación cubre todas las entradas de la operación; la clave y el identificador de tarea se escriben de forma duradera antes de esperar; los reinicios llaman a get o recover, nunca a submit, cuando existe una tarea; la prueba coincide con status pending, original_available false, signature_status not_checked, transaction_binding not_checked y verified false; pending y no disponible se asignan a un estado no concluyente sin liberar pedidos; una entrada distinta genera una clave nueva; una autorización caducada detiene el trabajo; y las notas dicen claramente que el ejemplo sintético no es aceptación en vivo ni permiso de negocio.
Revisar este producto
https://gridzen.ai/tools/mx-cep/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.
gridzen tools --product mx-cepFuentes y alcance
https://gridzen.ai/tools/mx-cep/ 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.