Skip to main content
Lerian SPI está dirigido por eventos. Las operaciones y los cambios de liquidación fluyen como eventos de dominio sobre el backbone de streaming de la plataforma. Los sistemas dependientes reaccionan a estos cambios sin sondeo. El riel nativo no tiene consumidores de webhook orientados al cliente. Su coordinación es interna a la plataforma.

​
Entrante desde el BACEN

El consumidor ICOM recibe mensajes ISO 20022 firmados del BACEN por la RSFN y los pasa a la entrada interna autenticada del riel. Un mensaje de transferencia de crédito (pacs.008) transporta un Pix entrante. Una respuesta de estado (pacs.002) informa de un pago que enviaste. Un mensaje de devolución (pacs.004) transporta una devolución. El riel valida cada mensaje entrante antes de aplicarlo. Un pago saliente permanece abierto hasta que llega su pacs.002; esa respuesta aplica COMPLETED o REJECTED. Un pacs.008 entrante se registra como pendiente y se completa o se rechaza mediante la decisión de fondeo del cliente autenticado. El riel registra los campos del BACEN de forma literal.

​
Flujo de eventos

Cada contexto del riel publica y consume los eventos que le pertenecen:
  • El contexto BR Code publica eventos de cobro y los eventos de la familia recurrente (Pix Automático). Consume eventos de liquidación para cerrar un cobro después de que su Pix se liquida.
  • El contexto Core consume eventos de confirmación de participante y eventos de finalización y terminación de liquidación. Mantiene el estado de participantes y operaciones en sincronía con el BACEN.

​
Integración con el ledger

Lerian SPI no mantiene ninguna posición contable propia. El riel emite eventos de liquidación sobre el backbone de streaming, y el consumidor de tu ledger registra la posición correspondiente. El riel transmite cada valor liquidado de forma literal. Cada evento de liquidación lleva un ce-id estable que identifica la liquidación; la entrega es al menos una vez, así que el consumidor de tu ledger debe deduplicar las reentregas por el ce-id.

​
Convenciones de API

  • La autenticación sigue el esquema estándar de token bearer de la plataforma.
  • Los pagos llevan un end-to-end ID. Lees un pago y su historial mediante el E2EID.
  • Las devoluciones son subrecursos. Creas y lees una devolución bajo el pago padre entrante que revierte. Debe solicitarse dentro de 90 días de la liquidación de ese pago y no puede llevar la suma de las devoluciones del Pix más allá del valor del propio Pix. La contraparte emite la devolución de un Pix que envió tu cliente, y llega como mensaje entrante.
  • Una devolución saliente concluye con la respuesta de BACEN. Un pacs.004 de salida que el riel despachó permanece en curso hasta que BACEN lo responda. Una solicitud duplicada de una devolución ya en curso se responde como en curso, y un identificador de devolución en colisión se responde como conflicto —nunca como un recibo.
  • Los mensajes entrantes del riel se validan por firma. El riel no aplica un mensaje que falla la validación.