ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações

Ir para o final dos metadados
Ir para o início dos metadados

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 5 Próxima »

Descrição dos componentes das regras de negócio

INFORMAÇÕES GERAIS

Momento

Componente

Detalhes

N/A

Casos de uso

Pagamentos múltiplos via Pix, de contas ou fornecedor

N/A

Nova API

Sim

N/A

Endereço base das APIs

  • Consentimento: /batch-consents

  • Pagamento: /pix/batch-payments

N/A

Role no diretório

CONTA, PAGTO

N/A

Iniciador terá acesso a notificações de status via

Webhook?

Sim, para consentimento e por pagamento¹

Consentimento

Pagamento

Qual gatilho da notificação (Webhook)?

Mudança de status do consentimento e mudança de status do pagamento¹

CONFIGURAÇÕES DO PAGAMENTO

Momento

Componente

Detalhes

Consentimento

Tempo para aprovação única

A aprovação deverá ocorrer até as 21h do dia previsto para liquidação do primeiro pagamento

Consentimento

Tempo para aprovação única

500 pagamentos

Consentimento

Permite múltiplos pagamentos para o mesmo

recebedor?

Sim

Consentimento

Prazo máximo para pagamentos agendados

180 dias

Consentimento

Valor do débito

Fixo

Consentimento

Responsável pela configuração e envio dos Pagamentos

Iniciador

Consentimento

Responsabilidade pela gestão da agenda de pagamento

O detentor da conta realiza as liquidações mediante solicitação do Iniciador, que deve enviar a lista a ser processada através da API /pix/batch-payments

Consentimento

Recebedor

PJ ou PF

Consentimento

Pagador

PJ ou PF

Consentimento

Permite Pagamentos imediatos

Sim

Consentimento

Fluxo de adesão

Consentimento único

Consentimento

Permite múltiplas alçadas?

Sim

Consentimento

Rejeição do consentimento

Iniciador e Detentor

  • Caso iniciador seja integrado ao sistema de gestão de pagamentos: Detentor deverá notificar o iniciador, via webhook (se disponível), e o iniciador decidir se e como notificar o pagador

  • Caso o iniciador não seja integrado ao sistema de gestão de pagamentos (iniciador “puro”): Detentor deverá notificar o iniciador, via webhook (se disponível), e o iniciador deve notificar o pagador

Consentimento

Permite adição de novos pagamentos?

Não. Uma vez autorizado o consentimento , não é permitido o envio de novos pagamentos além dos acordados.

Necessário novo consentimento

Consentimento

Permite edição de pagamentos?

Não. Uma vez enviada as informações de pagamento no consentimento, não é permitida a alteração destes pagamentos posteriormente.

Necessário novo consentimento

Consentimento

Consumação do consentimento

Após a tentativa de liquidação de todos os pagamentos possíveis ou após a data de liquidação do último pagamento. Detentor deve mover status do consentimento para CONSUMED

Consentimento

Pagamento

Comportamento em caso de erro no envio do pagamento no momento da liquidação

  • Iniciador: Corrigir as informações e reenviar o pagamento. Respeitando o prazo de liquidação de pagamento

  • Detentor: Retornar erro 422 com código específico

Consentimento

Condições de autorização do consentimento: necessário

listar todos os recebedores?

Sim

Consentimento

É possível habilitar crédito?

Permite que cliente escolha quanto à utilização no momento de autorização do consentimento

Consentimento

Tempo para envio dos dados dos pagamentos

Respeitando o prazo de liquidação de pagamento

Consentimento

Tempo para aprovação da múltipla alçada

A aprovação deverá ocorrer até o dia anterior ao primeiro pagamento, ou até a data/hora limite suportada pela detentora

PROCESSO DE LIQUIDAÇÃO

Momento

Componente

Detalhes

Pagamento

Canal para liquidação

A critério do PSP Pagador (Detentor)

  • Obs.: Caso o iniciador requisite apenas uma liquidação na transação, a liquidação ocorrerá via canal primário. Caso o iniciador requisite múltiplas liquidações na mesma requisição, a detentora, a seu critério, definirá o melhor canal para realização das liquidações¹

Pagamento

Onde o cliente cancela os pagamentos individuais?¹

Iniciador

Pagamento

Onde o cliente cancela o consentimento?

Iniciador e detentor

Pagamento

Erros de saldo insuficiente modificam o status do

consentimento?

Não

Pagamento

Iniciador é responsável pelo envio da ocorrência do

pagamento?

Sim, somente no momento da liquidação

Pagamento

Responsável pela geração do endToEndId

Iniciador

Pagamento

Qual é o localInstrument utilizado na liquidação?

MANU, DICT, INIC, QRCODE (QRDN, QRES)

Pagamento

Processo de liquidação dos pagamentos é interrompido

em caso de erro?

Não. Caso o iniciador envie múltiplos pagamentos na mesma requisição da API, a detentora deverá tentar liquidar todos os pagamentos enviados, seguindo a ordem da lista de envio (um a um)

Pagamento

Comportamento para retentativas

O detentor deverá permitir pelo menos três tentativas de liquidação, intradia, a pedido do iniciador

Pagamento

Funcionalidade de contestação

Não existe

Pagamento

Comportamento em dias não úteis

Permite pagamento

Pagamento

Utiliza limite Pix do cliente ou possui limite separado?

Utiliza limites Pix e conta do cliente

diagram_lote.png

  • Sem rótulos