Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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

...

Quantidade máxima de pagamentos

...

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.pngImage Removed