Pular para o conteúdo principal
As transferências P2P movem fundos entre contas da sua instituição na hora, 24 horas por dia. Uma transferência P2P pode ter uma tarifa. Veja Configuração de tarifas abaixo. A transferência nunca sai do seu sistema, então ela liquida de forma síncrona e dispensa a rede do BACEN.

​
Quando usar o P2P

O P2P é o tipo certo de transferência sempre que o remetente e o destinatário têm contas na sua instituição. Os cenários comuns incluem:
  • Mover dinheiro entre as contas do próprio cliente: um cliente transferindo da conta corrente para a conta poupança, ou entre duas contas que ele gerencia.
  • Pagar outro cliente da mesma instituição: um cliente enviando dinheiro para um amigo, um familiar ou uma empresa que também é cliente de vocês.
  • Movimentações internas de tesouraria: dividir saldos entre contas corporativas da mesma organização.
  • Divisão de pagamentos: distribuir valores entre várias contas para folha, divisão de despesas ou cashback.
O plugin detecta o P2P automaticamente. Quando o ISPB do destinatário corresponde ao ISPB da sua instituição, o plugin roteia a transferência internamente. Quando outro core da sua instituição compartilha o seu ISPB, o plugin primeiro pergunta ao JD Courier qual core detém a conta do destinatário. Veja Transferências entre cores. A sua integração de API é idêntica à do TED OUT, então você não precisa de um endpoint nem de uma lógica à parte. As duas contas devem estar na mesma organização do Midaz. Para contas em dois ledgers, veja Transferências entre ledgers.

​
Principais vantagens

​
Como funciona

O P2P reutiliza a mesma API do TED OUT, então a sua integração fica consistente entre os tipos de transferência. O processo tem duas etapas do ponto de vista do cliente: Diagrama do fluxo P2P
  1. Iniciar: o cliente envia os dados da transferência. O plugin valida o destinatário e calcula a tarifa. O cliente vê o resumo da transferência antes de efetivá-la.
  2. Confirmar: o cliente confirma. O plugin cria um débito + crédito atômico no Midaz. A transferência é concluída na hora.
O fluxo de duas etapas dá a você um momento natural para mostrar ao cliente uma tela de confirmação com o resumo completo da transferência antes de qualquer movimentação de fundos.

​
Estados da transferência

Diagrama da máquina de estados do P2P
O estado PENDING não se aplica às transferências P2P. O TED OUT usa PENDING enquanto o plugin prepara a mensagem para a JD. A retenção já existe desde CREATED. O P2P liquida inteiramente dentro do Midaz, então a transferência passa de CREATED por PROCESSING até COMPLETED. Uma transferência P2P não pode ser cancelada.

​
Configuração de tarifas

O modo de tarifa, MIDAZ_FEE_MODE, decide quem cobra a tarifa de uma transferência P2P. Veja Configuração do TED.

​
Validação do destinatário

O destinatário deve ter uma conta na mesma instituição. Quando você envia uma transferência, o plugin procura o destinatário no CRM. Ele compara os dados bancários que você informa: ISPB, agência, conta e documento do titular. Se o plugin não acha o destinatário, ele rejeita a transferência e não move fundos. O cliente deve conferir os dados da conta e tentar de novo. Se as duas contas estão em organizações diferentes do Midaz, o plugin recusa a transferência com 422 BTF-0004. Ele recusa dois ledgers diferentes da mesma forma, a menos que o tenant permita transferências entre ledgers.

​
Transferências entre ledgers

Um P2P pode mover fundos entre dois ledgers da mesma organização do Midaz. Isso vem desligado por padrão. Para ligar para um tenant, defina a política de tenant p2p.cross_ledger_enabled como true pela Admin API. O plugin lê essa configuração apenas quando você inicia uma transferência. Uma transferência entre dois ledgers precisa de todos estes itens: O plugin lança a transferência como um único grupo de ledgers do Midaz: os dois ledgers se movem, ou nenhum se move. A transferência guarda o ledger do pagador em ledgerId, o ledger do destinatário em recipientLedgerId e o grupo em ledgerGroupId.

​
Devolver uma transferência P2P

Você pode estornar uma transferência P2P concluída com Return a Transfer. A requisição precisa da permissão transfers:return. O ledger estorna a transação original na mesma requisição. A devolução é uma nova transferência P2P que debita a conta que recebeu a original e credita a conta que a pagou. O originalTransferId dela nomeia a original, que continua COMPLETED. A resposta é COMPLETED.
  • Uma devolução precisa do Midaz 4.1.3 ou posterior, ou 4.2.0 ou posterior entre dois ledgers.
  • A conta que recebeu a original deve ter o saldo para devolver.
  • Um P2P tem no máximo uma devolução ativa, e uma devolução não pode ser devolvida.
  • Se o resultado no ledger é desconhecido, a resposta é 503 BTF-2000, e a devolução continua CREATED. Envie a mesma requisição de novo com uma nova chave X-Idempotency. Ela retoma essa devolução e nunca cria uma segunda.

​
Integração técnica

O P2P usa os mesmos endpoints do TED OUT. Você não precisa de trabalho extra de integração além do fluxo de transferência de saída que já construiu.
O campo type na resposta da transferência é P2P. As transferências P2P não têm controlNumber, porque não passam pelo JD SPB.

​
Tratamento de erros

As transferências P2P são atômicas. Se qualquer parte falha, o Midaz não aplica nenhuma das pernas. Nenhum estado intermediário move fundos parcialmente nem deixa uma conta a descoberto. Se uma transferência falha, o cliente fica com o mesmo saldo e pode tentar de novo. Se /process responde 500 BTF-9014, o dinheiro se moveu, mas o plugin não registrou a transferência como concluída. Leia a transferência e envie de novo a mesma requisição /process com uma nova chave X-Idempotency. Não inicie uma nova transferência. Veja a lista completa de erros para os códigos de erro e a orientação de recuperação.