Un flujo de reversión es el conjunto de acciones necesarias para devolver el dinero al origen. Cuando ocurre un error en algún punto del flujo regular, se generan las acciones necesarias para revertir el movimiento de fondos. Al igual que las acciones regulares, estas acciones de reversión deben ser firmadas por las entidades financieras. Actualmente existen dos tipos de acciones asociadas al flujo de reversión:Documentation Index
Fetch the complete documentation index at: https://transfiya.me/llms.txt
Use this file to discover all available pages before exploring further.
- REJECT: es la acción que permite devolver el dinero del usuario destino al usuario origen. Es la acción opuesta a la acción principal (SEND / REQUEST). Esta acción es creada por TIN Cloud y firmada por la entidad financiera que actuó como receptora en la transacción a través del endpoint
/action. - REVERSE DOWNLOAD: es la acción que devuelve el dinero del usuario origen al banco origen. Es la inversa de la acción UPLOAD. Tanto la creación como la firma dependen del endpoint
/creditde la entidad financiera que actuó como origen.
Acciones realizadas por el flujo de reversión
Cuando inicia:- Cambia el estado de la transferencia a
ERROR. - Cambia el estado de la acción que falló a
ERROR(la acción principal pasa aREJECTED).
- Cambia el estado de la transferencia a
REJECTED. - Llama al endpoint
/status. - Llama a Motor de prevensión de fraude (341).
Definiciones y Validaciones
Si ocurre un error durante el proceso de reversión, la transferencia pasará a estadoERROR y será gestionada por el equipo de soporte.
El objeto error de la transferencia se enviará al endpoint /status del banco (solo si la transferencia tiene estado final REJECTED o COMPLETED).
Para revertir una acción, se deben cumplir las siguientes condiciones:
- La acción debe tener un
hash. - El proceso de reversión para la acción no debe haber sido iniciado previamente.
/continue con una acción en error mientras el flujo de reversión ya ha comenzado, la API ignorará la solicitud.
Comportamientos por tipo de error
- Si el endpoint
/debitretorna un error pero la acción UPLOAD fue completada, se llamará al endpoint/creditdel origen. - Si el error ocurre después de completar la acción principal (SEND o REQUEST), se creará una acción REJECT y se llamará al endpoint
/creditdel origen. - Si el error ocurre con una acción DOWNLOAD completada, se cambiará el estado de la transferencia a ERROR.
Validaciones en la respuesta de los bancos
La respuesta de los endpoints/debit, /transfer y /credit del banco será validada. Si la respuesta no cumple con los requisitos, la transferencia permanecerá en el estado anterior y no se generará flujo de reversión. La transacción se detendrá en el punto donde el banco no respondió correctamente.
Respuestas inválidas incluyen:
- Objeto vacío
- Acción sin
action_id - Acción sin
labels.tx_ref - Acción sin
labels.type - Acción sin
labels.status - Acción sin objeto
error(solo si la respuesta es un error) - Incoherencia en
codeymessage(por ejemplo, deben ser"code": 0, "message": "Success")
Impacto en el flujo
Flujo Asíncrono
- /debit: Sin efecto (el banco usa
/continue). - /transfer: Transferencia queda en
ACCEPTEDoERROR, acción principal enCOMPLETEDoPENDING. - /credit: Sin efecto (el banco usa
/continue).
Flujo Síncrono
- /debit: Transferencia queda en
INITIATED, acción UPLOAD enCOMPLETEDoPENDING. - /transfer: Transferencia queda en
ACCEPTEDoERROR, acción principal enCOMPLETEDoPENDING. - /credit: Transferencia queda en
ACCEPTEDoERROR, acción DOWNLOAD enCOMPLETEDoPENDING.