Acreditar al usuario destino es el último paso en el procesamiento de la transferencia. Para realizar esta operación, Transfiya llama al endpoint credit del banco destino y envía la acción principal (main action) en estado COMPLETED como payload.
El endpoint credit funciona de manera muy similar al endpoint debit, pero contempla un escenario adicional que debe ser manejado correctamente:
El crédito se utiliza tanto para acreditar al usuario destino —que es el caso más común de este endpoint— como para acreditar al usuario origen en escenarios de error, cuando los fondos deben ser devueltos al origen.
La implementación de la operación es la misma; la única diferencia está en determinar si se debe acreditar al origen o al destino de la acción principal. Esta decisión se toma en función del estado de la acción principal:
Si el estado de la acción principal es COMPLETED → caso exitoso, se debe acreditar al destino de la acción principal.
Si el estado de la acción principal es REJECTED → caso de reversa, se debe acreditar al origen de la acción principal para devolver los fondos a la cuenta de origen en caso de errores durante el procesamiento.
Una vez que la transferencia ha sido aprobada y confirmada por el banco originador, Transfiya procede a acreditar los fondos en la cuenta del usuario receptor. Este proceso se realiza mediante una llamada al endpoint credit del banco destino, la cual activa una nueva acción de tipo DOWNLOAD en el sistema.
El flujo de acreditación contempla tanto casos exitosos como escenarios de reversa. En ambos casos, el procedimiento técnico es el mismo: el banco receptor valida la información de la cuenta, acredita los fondos y firma un objeto IOU que sirve como prueba criptográfica de la operación.
A continuación, se describe el paso a paso de este proceso:
1
Transfiya llama al banco destino para procesar la operación de abono.
Se invoca el endpoint credit con todos los datos necesarios para iniciar el abono de fondos.
El banco destino crea una acción de tipo `DOWNLOAD` en Transfiya.
Esta acción representa la operación de crédito y se registra con estado inicial PENDING.
mainAction en los valores hace referencia a los datos de la acción principal que se recibe desde Transfiya. En otras palabras, representa el cuerpo de una llamada POST https://ban.co/transfiya/credit.
bankSigner representa el firmante de liquidación que es registrado por el banco durante su incorporación con Transfiya. Este firmante mantiene el balance total disponible para el banco dentro del sistema.
mainAction.snapshot.target.signer.handle — Usuario destino de la transferencia (cliente del banco).
target
bankSigner.handle — Firmante de liquidación del banco destino.
symbol
mainAction.symbol — Moneda de la transferencia.
amount
mainAction.amount — Monto de la transferencia.
labels.type
DOWNLOAD — Siempre debe ser DOWNLOAD en operaciones de crédito.
labels.tx_ref
mainAction.labels.tx_ref — Referencia única de la transferencia.
labels.received
Timestamp en formato ISO 8601 — Momento en que Transfiya recibió la solicitud de abono.
labels.dispatched
Timestamp en formato ISO 8601 — Momento en que se envió la solicitud de creación de la acción a Transfiya.
mainAction en los valores hace referencia a los datos de la acción principal que se recibe desde Transfiya. En otras palabras, representa el cuerpo de una llamada POST https://ban.co/transfiya/credit.
bankSigner representa el firmante de liquidación que es registrado por el banco durante su incorporación con Transfiya. Este firmante mantiene el balance total disponible para el banco dentro del sistema.
mainAction.snapshot.target.signer.handle — Usuario destino de la transferencia (cliente del banco).
target
bankSigner.handle — Firmante de liquidación del banco destino.
symbol
mainAction.symbol — Moneda de la transferencia.
amount
mainAction.amount — Monto de la transferencia.
labels.type
DOWNLOAD — Siempre debe ser DOWNLOAD en operaciones de crédito.
labels.tx_ref
mainAction.labels.tx_ref — Referencia única de la transferencia.
labels.received
Timestamp en formato ISO 8601 — Momento en que Transfiya recibió la solicitud de abono.
labels.dispatched
Timestamp en formato ISO 8601 — Momento en que se envió la solicitud de creación de la acción a Transfiya.
Pueden añadirse campos adicionales a estas respuestas como parte de nuevas funcionalidades. Las implementaciones de los bancos DEBEN ser resilientes ante la adición de nuevos campos.
La respuesta de error se devuelve cuando una solicitud no es válida, cuando quien llama no tiene los permisos suficientes o cuando el sistema se encuentra en mantenimiento.
El código de estado HTTP para errores será 4xx o 5xx. El cuerpo de la respuesta puede incluir información adicional del error en el formato descrito anteriormente, si dicha información está disponible.
Copy
{ "error": { "code": 121, "message": "Signer not found in database." }}
3
El banco responde a la llamada inicial de abono.
Esta respuesta cierra la parte síncrona de la operación; el resto se ejecuta de forma asíncrona.
El <download_action_id> en la URL representa el ID de la acción de tipo DOWNLOAD creada en el paso 2. En el ejemplo, este valor es 2aa49d5d-3dcc-4841-bb3e-baeb9fef4278.
labels.tx_id
Identificador único de la transacción que el banco ejecutó para acreditar los fondos en la cuenta de destino.
El <download_action_id> en la URL representa el ID de la acción de tipo DOWNLOAD creada en el paso 2. En el ejemplo, este valor es 2aa49d5d-3dcc-4841-bb3e-baeb9fef4278.
labels.tx_id
Identificador único de la transacción que el banco ejecutó para acreditar los fondos en la cuenta de destino.
El banco crea y firma un objeto IOU como prueba de la operación.
El IOU incluye los datos del abono y debe ser firmado criptográficamente.
Transfiya valida la firma del objeto IOU recibido y lo almacena en el libro mayor si todo es válido. Esta operación también marca la acción DOWNLOAD como COMPLETED.
El IOU se utiliza como prueba de que una operación ha sido realizada en el core bancario. Debe coincidir exactamente con la acción que representa. Por este motivo, la mayoría de los datos del IOU se copian desde el objeto downloadAction.
Transfiya utiliza firmas criptográficas como prueba de que los participantes autorizaron los movimientos de saldo. Los datos se hashean primero y luego se firman utilizando claves privadas que nunca deben compartirse con TransfiYa. Los algoritmos de firma y hash están documentados, y los SDKs de TransfiYa permiten realizar estas operaciones de forma sencilla para facilitar la integración.
El <download_action_id> en la URL es el ID de la acción de tipo DOWNLOAD creada en el paso 2. En el ejemplo es 2aa49d5d-3dcc-4841-bb3e-baeb9fef4278.
data.source
downloadAction.snapshot.source.signer.handle – Firmante fuente del abono.
data.target
downloadAction.snapshot.target.signer.handle – Firmante destino del abono.
data.symbol
downloadAction.snapshot.symbol.signer.handle – Identificador del símbolo o moneda.
data.amount
downloadAction.amount – Monto a acreditar.
data.domain
downloadAction.labels.domain – Dominio asociado a la transacción.
data.expiry
currentTime + 1 minuto en formato ISO 8601 – Momento a partir del cual Transfiya puede expirar una operación pendiente.
hash
Hash del objeto data, generado por los SDKs. hash.value es el valor calculado, y los demás campos indican los pasos de hash.
meta.signatures
Firma del hash generada con la clave privada del firmante fuente. Incluye: schema (algoritmo), signer, public (clave pública) y string (firma).
Transfiya valida la firma del objeto IOU recibido y lo almacena en el libro mayor si todo es válido. Esta operación también marca la acción DOWNLOAD como COMPLETED.
El IOU se utiliza como prueba de que una operación ha sido realizada en el core bancario. Debe coincidir exactamente con la acción que representa. Por este motivo, la mayoría de los datos del IOU se copian desde el objeto downloadAction.
Transfiya utiliza firmas criptográficas como prueba de que los participantes autorizaron los movimientos de saldo. Los datos se hashean primero y luego se firman utilizando claves privadas que nunca deben compartirse con TransfiYa. Los algoritmos de firma y hash están documentados, y los SDKs de TransfiYa permiten realizar estas operaciones de forma sencilla para facilitar la integración.
El banco realiza validaciones finales y envía una llamada `continue`.
Esta llamada indica que el flujo puede continuar. Debe incluir los campos received y dispatched requeridos por regulación.
Para continuar con el procesamiento de la transferencia, basta con llamar al endpoint continue y proporcionar las marcas de tiempo requeridas por la regulación.
El campo <tx_ref> en la URL representa la referencia de la transferencia, ubicada en labels.tx_ref del mainAction.
received
Timestamp en formato ISO 8601. Representa el momento en que se recibió la última respuesta de Transfiya (llamada sendit).
dispatched
Timestamp en formato ISO 8601. Representa el momento en que se envió la llamada continue a Transfiya.
Para continuar con el procesamiento de la transferencia, basta con llamar al endpoint continue y proporcionar las marcas de tiempo requeridas por la regulación.
El campo <tx_ref> en la URL representa la referencia de la transferencia, ubicada en labels.tx_ref del mainAction.
received
Timestamp en formato ISO 8601. Representa el momento en que se recibió la última respuesta de Transfiya (llamada sendit).
dispatched
Timestamp en formato ISO 8601. Representa el momento en que se envió la llamada continue a Transfiya.
Los bancos pueden reportar errores en la parte asincrónica del procesamiento de una transferencia llamando al endpoint continue e incluyendo un objeto error en el cuerpo de la solicitud con información adicional sobre el error.
Los códigos de error devueltos por los bancos deben estar en el rango 3xx.