Skip to main content
O Lerian SPI é orientado a eventos. As operações e as mudanças de liquidação fluem como eventos de domínio sobre o backbone de streaming da plataforma. Os sistemas dependentes reagem a essas mudanças sem polling. O trilho nativo não tem consumidores de webhook voltados ao cliente. A sua coordenação é interna à plataforma.

​
Entrada do BACEN

O consumidor ICOM recebe mensagens ISO 20022 assinadas do BACEN pela RSFN e as encaminha para a entrada interna autenticada do trilho. Uma mensagem de transferência de crédito (pacs.008) transporta um Pix recebido. Uma resposta de status (pacs.002) informa um pagamento que você enviou. Uma mensagem de devolução (pacs.004) transporta uma devolução. O trilho valida cada mensagem de entrada antes de aplicá-la. Um pagamento de saída permanece aberto até que o seu pacs.002 chegue; essa resposta aplica COMPLETED ou REJECTED. Um pacs.008 de entrada é registrado como pendente e é concluído ou recusado pela decisão de funding do cliente autenticado. O trilho registra os campos do BACEN de forma literal.

​
Fluxo de eventos

Cada contexto do trilho publica e consome os eventos que lhe pertencem:
  • O contexto BR Code publica eventos de cobrança e os eventos da família recorrente (Pix Automático). Ele consome spi.payment.settled para encerrar uma cobrança após a liquidação do seu Pix e spi.mandate.resolved para tirar um mandato do Pix Automático de CRIADA.
  • O contexto Core consome eventos de confirmação de participante e eventos de conclusão e término de liquidação. Ele mantém o estado de participantes e operações em sincronia com o BACEN.

​
Integração com o ledger

O Lerian SPI não mantém nenhuma posição contábil própria. O trilho emite eventos de liquidação sobre o backbone de streaming, e o consumidor do seu ledger registra a posição correspondente. O trilho transmite cada valor liquidado de forma literal. Cada evento de liquidação carrega um ce-id estável que identifica a liquidação; a entrega é pelo menos uma vez, então o consumidor do seu ledger deve deduplicar as reentregas pelo ce-id.

​
Convenções de API

  • A autenticação segue o esquema padrão de token bearer da plataforma.
  • Os pagamentos carregam um end-to-end ID. Você lê um pagamento e o seu histórico pelo E2EID.
  • As devoluções são subrecursos. Você cria e lê uma devolução sob o pagamento pai de entrada que ela reverte. Ela precisa ser solicitada em até 90 dias da liquidação daquele pagamento e não pode levar a soma das devoluções do Pix além do valor do próprio Pix. A contraparte emite a devolução de um Pix que seu cliente enviou, e ela chega como mensagem de entrada.
  • Uma devolução conclui com a resposta do BACEN. Um pacs.004 que o trilho despachou permanece em andamento até o BACEN responder. Uma solicitação duplicada de uma devolução já em andamento é respondida como em andamento, e um identificador de devolução em colisão é respondido como conflito — nunca como um recibo.
  • As mensagens recebidas pelo trilho são validadas por assinatura. O trilho não aplica uma mensagem que falha na validação.