Versões comparadas

Chave

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

...

Regras de negócio

INFORMAÇÕES GERAIS

Momento

Componente

Detalhes

Definição

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
  • (permite mais de 500 transações por lote)

  • Pagamentos gerenciados pela iniciadora e pela detentora de conta

-

Cenários

▪ Autorização via automação, em plataformas de gestão de pagamento intermediárias, com

autorização de pagamento do lote sob configurações pré-definidas (consentimento de longa

duração (equivalente ao nível funcional de VAN, BaaS))

▪ Em casos de múltipla alçada, utiliza-se consentimento de longa duração

-

Exemplo prático

  1. Empresa pagadora Define um usuário para pagamento com valor limitado

  2. Empresa pagadora com ITP/ERP: Manifesta a intenção de pagar um lote

  3. ITP/ERP com Detentora: Cria o consentimento de longa duração

  4. Detentora com Detentora: Valida os limites do operador

  5. ITP/ERP com Empresa pagadora: Solicita autorização do consentimento

  6. Empresa pagadora com Detentora: Autoriza o consentimento de longa duração

  7. ITP/ERP com Detentora: Envia os pagamentos em lote

  8. Detentora com ITP/ERP: Confirma ou rejeita o pagamento

-

Responsabilidade da gestão do pagamento

Iniciador

-

Liability para autorização do pagamento

Limites configurados no consentimento de longa duração precisam ser respeitados pela detentora

-

Nova API

SIM

-

Canal de liquidação

Secundário

-

Role no diretório

CONTA, PAGTO

N/A

-

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

Webhook?

Sim, para consentimento e por

pagamento¹

pagamento

Consentimento

-

Pagamento

Qual gatilho da notificação (Webhook)?

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

pagamento¹

pagamento

CONFIGURAÇÕES DO PAGAMENTO

Momento

Componente

Detalhes

Definição

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

(quando não há múltipla alçada)

  • O consentimento é sempre criado com o status AWAITING_AUTHORISATION. Ele pode ser aprovado somente antes do tempo de expiração de 15 minutos, assumindo o status AUTHORISED. Se não, deve assumir o status REJECTED caso expire ou seja cancelado pelo usuário

  • Lembrando que o usuário pode cancelar o consentimento no lado da detentora de conta e por sua vez ela deve mudar o status do consentimento para REJECTED

Consentimento

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

Esse não possui prazo de expiração e a alteração desse status depende da política de cada detentora de conta

Consentimento

Permite múltiplos consentimentos ativos?

Sim

Consentimento

Quantidade máxima de pagamentos por consentimento

Pode ser limitado pelos limites definidos no consentimento

Consentimento

Quantidade de pagamentos em um lote

10000

Consentimento

Quantidade de lotes por consentimento

Pode ser limitado à critério do cliente

Consentimento

Permite múltiplos pagamentos para o mesmo recebedor?

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

Sim

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

Consentimento

Pagamento

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

Iniciador: Corrigir as informações

Necessário cancelamento do pagamento original e criação de um novo pagamento

Consentimento e

Pagamento

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: Após consumido o valor limite estabelecido OU após a expiração do consentimento (data fim estabelecida) (se houver um dos limites)

▪ Pagamento: Iniciador deve corrigir as informações ou avisar o cliente para resolução do problema (saldo/limite) 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

. Obs.: Podem ocorrer erros não tratáveis, ou não haver tempo hábil para reenvio dos pagamentos

Consentimento

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

Iniciador

Consentimento

Recebedor

PJ ou PF

Consentimento

Pagador

PJ

Consentimento

Permite pagamentos imediatos

Não, apenas uso do canal secundário

Consentimento

Permite pagamento para o mesmo dia?

Sim

Consentimento

Fluxo de adesão

Consentimento de longa duração

Consentimento

Permite múltiplas alçadas?

Sim

Consentimento

Valor do débito

Variável

PROCESSO DE LIQUIDAÇÃO

Momento

Componente

Detalhes

Definição

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¹

Prazo máximo para pagamentos agendados

180 dias

Pagamento

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

  • Detentor avisa a iniciador (via webhook, se implementado; ou, via GET/API) com o código de erro,e iniciador avisa o cliente.

  • Detentor também, obrigatoriamente, notifica cliente.

Pagamento

Onde o cliente cancela os pagamentos

individuais

do lote?

¹

Cliente cancela no Iniciador ou no seu cliente/Detentor

Pagamento

Onde o cliente cancela

o consentimento

os pagamentos individuais?¹

Iniciador e detentor

Cliente cancela no Iniciador ou no seu cliente/Detentor

Pagamento

Canal para liquidação

Canal secundário

Pagamento

Erros de saldo insuficiente modificam o status do

Pagamento

consentimento?

Não

Pagamento

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

pagamento?

Sim, somente no momento da liquidação

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

do lote de pagamentos é interrompido em

em

caso de erro em um pagamento?

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

...

, conta do cliente e limite do consentimento

OUTROS

Gestão do Consentimento

Onde o cliente cancela o consentimento?

Iniciador e detentor

Gestão do Pagamento

Onde o cliente cancela o pagamento agendado?

Conforme regra do arranjo (Pix agendado)