O plugin aceita transferências e devoluções intra-PSP. Ele as liquida internamente e reporta cada uma ao BACEN pelo TRCK002.
Detecção
O plugin marca uma transferência como intra-PSP quando o ISPB de destino corresponde ao ISPB do pagador, o
bankingDetails.bankId da conta alias do pagador no CRM:
A detecção é interna. A resposta da iniciação e o status do cash-out são iguais aos de uma transferência externa. O plugin roteia uma transferência intra-PSP pelo caminho de liquidação interno em vez do BTG. Uma cobrança de Pix Saque ou Pix Troco não pode liquidar internamente: o plugin a rejeita com
PIX-0497 (422).
Modelo de processamento
Uma transferência intra-PSP usa o mesmo roteamento no Midaz que uma transferência externa, pela conta de trânsito
@external. O comportamento no ledger é idêntico. O plugin liquida a transferência de forma síncrona e não espera pelos webhooks do BTG.
O plugin cria duas transações no Midaz por transferência:
- Cashout:
source → @external(pending: false) - Cashin:
@external → destination(pending: false)
Fluxo
O cash-out responde com
PROCESSING, como um cash-out externo que espera pelo BTG. O plugin entrega o status final (COMPLETED ou REJECTED) de forma assíncrona por um webhook de saída. O endpoint intra-PSP é idempotente, então novas tentativas do worker nunca duplicam transações.Reporte regulatório TRCK002
O plugin reporta ao BACEN cada transação intra-PSP bem-sucedida pelo endpoint TRCK002 do BTG.
- O reporte TRCK002 é não bloqueante. Uma falha no reporte nunca reverte a transação no Midaz nem a conclusão da transferência. O plugin faz nova tentativa de um reporte que falhou.
- O plugin cria um relatório de transação para cada transação. Depois que o BTG aceita o envio, o status do relatório passa para
PROCESSINGe carrega umpactualId. - O BTG envia atualizações de status do relatório por um webhook CAMT025, do tipo
PIX_INTERNAL_TRANSACTIONS_REPORT. O webhook move o relatório paraCONFIRMED(terminal) ouERROR(recuperável). - Você também pode consultar um relatório pelo ID end-to-end ou pela identificação de devolução quando um webhook não chega.
Devoluções intra-PSP
O plugin também processa uma devolução internamente quando o cash-in original foi intra-PSP:
- O plugin detecta intra-PSP a partir da transferência original, quando o ISPB de origem e o de destino coincidem.
- Ele debita o solicitante da devolução (
requester → @external). Depois entrega o cash-in da devolução ao remetente original pelo mesmo padrão de fila e endpoint. - O plugin reporta a devolução ao TRCK002 com uma
returnIdentification. - O plugin envia um webhook
REFUND/CASHOUTpara o solicitante da devolução e um webhookREFUND/CASHINpara o remetente original.
Próximos passos
- Webhooks: Envelope de evento, novas tentativas e roteamento
- Operações de devolução: Devoluções distribuídas e desbloqueio
- Configurar a integração: Configuração de ISPB e do worker
- Referência da API: Documentação completa da API

