1 - Histórico de versionamento
...
Versão
...
Descrição
...
Responsável
...
Data
...
0.1
...
Versão inicial do Guia de implementação
...
José Xavier (Sensedia - DTO)
...
15/09/2023
...
0.2
...
Adição do bpmn para o fluxo de adesão e liquidação para Pix Automático e Sweeping Accounts;
Descrição de alguns passos para o bpmn do fluxo de adesão;
...
José Xavier (Sensedia - DTO)
...
20/09/2023
...
0.3
...
Adição de tópico sobre possibilidade de edição de consentimentos para Pix Automático;
Adição de orientações sobre passos da Liquidação do Pix Automático - Clarificação sobre o pagamento imediato;
Adição de menção ao Webhook em substituição ao polling na consulta de consentimentos;
Ajuste no JSON de exemplo para Adesão de Pix Automático: adicionado campo “period” com valor “MENSAL”;
...
José Xavier (Sensedia - DTO)
...
12/10/2023
...
0.4
Adição das regras de revogação e motivos de rejeição síncronos e assíncronos;
Adicionadas regras de consumação de consentimentos de longa duração;
Orientações sobre o preenchimento do additionalInformation para agendamentos recorrentes com datas customizadas;
...
José Xavier (Sensedia - DTO)
...
13/10/2023
...
0.5
...
Adição da explicações adicionais sobre os produtos Pix Automático e Sweeping Accounts:
Explicação dos passos do fluxo de liquidação de ambos os produtos;
Explicação de erros do sweeping relacionados a limites;
Orientações quanto ao envio dos sinais de risco;
Orientações quanto a edição do consentimento de longa duração;
Orientações para consultas com endpoint GET /pix/recurring-payments;
Orientações sobre CNPJ de mesma raiz;
Orientações sobre a geração do endToEndId
...
José Xavier (Sensedia - DTO)
...
17/10/2023
...
1.0
...
Publicação da primeira versão na área do desenvolvedor
...
José Xavier (Sensedia - DTO)
...
Informações |
---|
O Guia segue seu próprio versionamento. Cada versão do documento é salva com um numero incremental: 0.1, 0.2, 0.3 sucessivamente, até que a versão do documento seja aprovada e publicada. Com a publicação, passa a ser versão 1.0. Versões editadas subsequentemente a versão inicial publicada, passam a ser 1.1, 1.2, ..., 1.x. Sendo "x" um número que represente mudanças pequenas, conhecidas como minor. Se a mudança proposta for considerada uma major, mudamos a numeração completa, indo para 2.0, 3.0, etc. O GT especificações e serviços será o responsável por definir o versionamento do documento para cada uma das alterações futuras. |
...
No quadro abaixo, entraremos com mais detalhes sobre as regras de negócio de cada um dos produtos de pagamento automáticos, o que deve-se considerar quando consumir o serviço e quais são os parâmetros necessários para utilizar corretamente os tipos de pagamentos descritos e passíveis de realização em seus diferentes modelos.
| Pagamento Automático | Sweeping Accounts |
---|---|---|
Casos de uso | Utilities/serviços públicos, assinaturas, escolas, academias, aluguel, seguros, cobranças de pagamento de operação de crédito | Sweeping accounts e similares (investimentos inteligentes, proteção contra uso desnecessário de cheque especial) |
Configurações de recorrência | ||
Motor de recorrência | Criação de um consentimento para recorrência com limites de quantidade, valores e prazos | Criação de um consentimento para recorrência com limites de quantidade, valores e prazos |
Valor | Fixo ou variável | Fixo ou variável |
Modelo de recorrência, intervalos de pagamentos | Diário, semanal, mensal ou anual, atentando-se aos dias úteis e regras dos feriados locais, considerar o dado do cadastro do pagador na detentora. | Restrito aos limites definidos no consentimento |
Gestão da Agenda | Compartilhada: Iniciador tem visibilidade completa, PSP pagador tem visibilidade com antecedência de 2 a 10 dias das próximas incidências | Iniciador |
Comanda o pagamento | Iniciador | Iniciador |
Recebedor | PJ | PN ou PJ de mesma titularidade |
Primeiro pagamento | Imediato ou Agendado | Imediato |
Demais pagamentos | Agendado | Imediato |
Permite pagamentos imediatos | Sim | Sim |
Definição do final do período da recorrência | Opcional | Opcional |
Prazo máximo de duração para recorrência do consentimento | Opcional | Opcional |
Permite a configurar data de início do consentimento? | Sim | Sim |
Permite a configurar data de expiração do consentimento? | Sim | Sim |
Permite limites globais do consentimento?¹ | Não | Não |
Permite limites periódicos por consentimento? | Não | Sim |
Permite limites por transação? | Sim | Sim |
Processo de adesão | ||
Fluxo de adesão | Consentimento FAPI long-lived tokens | Consentimento FAPI long-lived tokens |
Role no diretório | CONTA, PAGTO | CONTA, PAGTO |
Será possível editar configurações de recorrência no processo de adesão no Detentor? | Não | Não |
Cancelamento do fluxo da adesão | Via Iniciador ou Detentor | Via Iniciador ou Detentor |
Permite múltiplas alçadas? | Sim | Sim |
Iniciador terá acesso aos status do processo de adesão via Webhook? | Sim | Sim |
Adesão tem id de contrato? | Sim | Não |
Gestão de adesão | ||
Permite edição técnica dos dados do consentimento pós adesão²? | Sim, verificar no link | Sim, verificar no link |
Cancelamento da adesão | Pelo pagador, no ambiente da iniciadora ou detentora | Pelo pagador, no ambiente da iniciadora ou detentora |
Revogação da adesão | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude |
Consumação³ da adesão? | Detentor | Detentor |
Processo de liquidação | ||
Canal para liquidação | Serão utilizados os canais primário e secundário (obedecendo as regras da trilha Pix, com liquidações em dias úteis). Quem deverá criar o E2EID com a data do próximo dia útil é o iniciador, com base no cadastro do usuário pagador no detentor | Primário |
Dispara o pagamento⁴ | Detentor | Iniciador |
Onde o cliente cancela o pagamento? | Iniciadora ou Detentora | Não é possível |
Erros de saldo insuficiente modificam o status do consentimento? | Se pagamento imediato falhar, sim. | Não |
Listagem das informações do pagamento | Busca por id do consentimento | Busca por id do consentimento |
Iniciador é responsável pelo envio da ocorrência do pagamento? | Sim, no prazo de 2 a 10 dias anteriores a data da ocorrência do pagamento | Sim, imediatamente |
Quem avisa o pagador sobre pagamento com falha? | Iniciador e Detentor⁵. Detentor deverá notificar o iniciador e o iniciador decidir se e como notificar o pagador | Iniciador |
Responsável pela geração do endToEndId | Iniciador | Iniciador |
A data agendada no consentimento e a data agendada do E2EID podem ser distintas? | Sim, em casos de finais de semana e feriados as datas podem ser alteradas. Atenção aos dias 29, 30 de fevereiro, a liquidação ocorre no próximo dia útil. | Não |
Qual é o localInstrument utilizado na liquidação? | MANU | DICT e INIC |
Outras informações | ||
É possível habilitar crédito? | Seguir a regra do arranjo. Habilitar na detentora no momento da adesão do consentimento. Na confirmação do consentimento é necessário um aviso ao cliente que o uso de linha de crédito pré-aprovada na instituição detentora de conta está habilitado e poderá ser alterado na detentora em ambiente de gestão do Pix automático. | Sim – Deverá ser debatido, em conjunto com PRC e BC, a maneira de habilitar esse crédito e as configurações do consentimento |
Retentativas
| Primeira tentativa das 0h – 8h. Segunda tentativa entre 15h – 17h. Não aplicável para o dia seguinte. | Não |
Funcionalidade de contestação | Cliente deverá entrar em contato com o recebedor - Discutir com o BC como adotar no Open Finance e se adotar. | Não |
Legenda
1 - Limite específico para um determinado consentimento, por exemplo, limite de R$100 por dia (periódico) ou R$300 para o intervalo do consentimento (global)
2 - O GT questionou o BC sobre o comportamento esperado quando houver a edição –se o usuário deverá ser redirecionado para a detentora ou não para confirmar os novos dados do consentimento
3 - Entende-se como consumação a mudança do estado, por exemplo, após 10/10 parcelas o estado será alterado de aprovado para consumido
4 - Responsável por garantir que no momento do agendamento a liquidação ocorra
5 - GT está avaliando se existe alguma normativa que obrigue uma das partes avisar ao pagador
...
Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, o Pix Automático e o Sweeping Accounts possuem consentimentos de longa duração, os quais poderão ser editados ao longo da sua vida útil. Entraremos mais no detalhe do processo de adesão a seguir.
4.1.1 - Fluxo da adesão
...
ID | CAMADA | TIPO | DESCRIÇÃO |
---|---|---|---|
1 | Usuário Pagador | Ação | Pagador acessa ambiente do recebedor e manifesta a intenção de contratar um dos serviços ofertados. |
2 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador seleciona o Pix Automático via Open Finance como forma de pagamento pelo serviço. |
3 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador informa seus dados de pagamento e, opcionalmente, configura parâmetros de limite para a transação. |
4 | Usuário Pagador | Comunicação | Em ambiente do Recebedor: Dados são repassados ao Iniciador. |
5 | Iniciador | Comunicação | Recebe os dados enviados do Recebedor e inicia o processo de criação do consentimento. |
6 | Iniciador | Ação | Valida as informações recebidas do Recebedor. |
7 | Iniciador | Comunicação | Solicita ao Detentor o access_token para a criação do consentimento. |
8 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
9 | PSP Pagador (Detentor) | Ação | Processa a solicitação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
10 | PSP Pagador (Detentor) | Comunicação | Retorna ao Iniciador o access_token solicitado. |
11 | Iniciador | Comunicação | Recebe o access_token enviado pelo Detentor. |
12 | Iniciador | Ação | Iniciador prepara o payload de envio do consentimento de longa duração atentando-se ao produto para o qual este consentimento está sendo criado. |
13 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor. |
14 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. |
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento de longa duração. |
16 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. |
17 | Iniciador | Comunicação | Recebe o sucesso na criação do consentimento de longa duração e URL de redirecionamento. |
18 | Iniciador | Ação | Processa o retorno da solicitação de criação do consentimento de longa duração. |
19 | Iniciador | Comunicação | Redireciona o pagador para autenticação no Detentor. |
20 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Realiza a autenticação. |
21 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Autoriza o consentimento. |
22 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED. |
23 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador notifica os demais aprovadores solicitando a aprovação em caso de múltiplas alçadas. |
24 | Usuário Pagador | Comunicação | Redireciona o usuário para a aplicação do Iniciador. |
25 | Iniciador | Comunicação | Recebe informações do redirecionamento. |
26 | Iniciador | Ação | Valida informações recebidas. |
27 | Iniciador | Ação | Consulta status do consentimento. |
28 | Iniciador | Comunicação | Notifica o recebedor do sucesso na adesão. |
29 | PSP Recebedor | Comunicação | Recebe notificação do sucesso da adesão. |
30 | Iniciador | Comunicação | Notifica o pagador do sucesso na adesão. |
31 | Usuário Pagador | Comunicação | Recebe a notificação de sucesso. |
Agora, precisamos detalhar melhor o comportamento esperado tanto do Iniciador quanto do Detentor em alguns dos passos descritos acima, são eles:
...
4.2.1 - Fluxo para liquidação do Pix Automático
...
ID | CAMADA | TIPO | DESCRIÇÃO |
---|---|---|---|
1 | Empresa Recebedora | Ação | Inicia processo de cobrança. |
2 | Empresa Recebedora | Ação | Busca informações de pagamento do usuário. |
3 | Empresa Recebedora | Comunicação | Envia cobrança para o Iniciador. |
4 | Iniciador | Comunicação | Recebe solicitação de cobrança. |
5 | Iniciador | Ação | Valida informações recebidas. |
6 | Iniciador | Comunicação | Envia solicitação de access_token. |
7 | PSP Pagador (Detentor) | Comunicação | Recebe solicitação de access_token. |
8 | Detentor | Ação | Processa solicitação de access_token. |
9 | Detentor | Comunicação | Retorna acess_token. |
10 | Iniciador | Comunicação | Recebe access_token. |
11 | Iniciador | Ação | Processa retorno da solicitação de access_token. |
12 | Iniciador | Ação | Cria a solicitação de pagamento. |
13 | Iniciador | Comunicação | Envia solicitação de pagamento. |
14 | PSP Pagador (Detentor) | Comunicação | Recebe solicitação de pagamento. |
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de pagamento. |
16 | PSP Pagador (Detentor) | Ação | Realiza a cobrança na conta de débito do pagador. |
17 | PSP Pagador (Detentor) | Ação | Agenda o pagamento futuro conforme solicitado. |
18 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na solicitação de pagamento e/ou agendamento de pagamento. |
19 | Iniciador | Comunicação | Recebe sucesso na solicitação de pagamento e/ou agendamento de pagamento. |
20 | Iniciador | Ação | Processa o retorno da criação de pagamento. |
21 | Iniciador | Ação | Consulta informações do pagamento. |
22 | Iniciador | Comunicação | Notifica ao recebedor sucesso na transferência. |
23 | Empresa Recebedora | Comunicação | Recebe notificação de sucesso na transferência. |
24 | Empresa Recebedora | Ação | Processamento interno do pagamento. |
25 | Empresa Recebedora | Comunicação | Notifica pagador do sucesso na transferência. |
26 | Usuário Pagador | Comunicação | Recebe notificação de sucesso na transferência. |
Agora, precisamos detalhar melhor o comportamento esperado tanto do Iniciador quanto do Detentor em alguns dos passos descritos acima, são eles:
...
4.2.2- Fluxo de liquidação do Sweeping Accounts
...
ID | CAMADA | TIPO | DESCRIÇÃO |
---|
ID | CAMADA | TIPO | DESCRIÇÃO |
---|---|---|---|
1 | Iniciador | Ação | Dispara processo de transferência |
2 | Iniciador | Ação | Busca informações de contas de usuário habilitadas por ele para realização da transferência |
3 | Iniciador | Ação | Analisa as regras definidas pelo usuário pagador no momento da criação do consentimento de longa duração |
4 | Iniciador | Comunicação | Envia solicitação de access_token |
5 | PSP Pagador | Comunicação | Recebe solicitação de access_token |
6 | PSP Pagador | Ação | Processa solicitação de access_token |
7 | PSP Pagador | Comunicação | Retorna access_token |
8 | Iniciador | Comunicação | Recebe access_token |
9 | Iniciador | Ação | Processa retorno da solicitação de access_token |
10 | Iniciador | Ação | Cria solicitação de transferência |
11 | Iniciador | Comunicação | Envia a solicitação de transferência |
12 | PSP Pagador | Comunicação | Recebe solicitação de transferência |
13 | PSP Pagador | Ação | Processa solicitação de transferência |
14 | PSP Pagador | Ação | Realiza a transferência de fundo |
15 | PSP Pagador | Comunicação | Retorna sucesso na solicitação de transferência |
16 | Iniciador | Comunicação | Recebe sucesso na transferência |
17 | Iniciador | Ação | Processa o retorno da transferência |
18 | Iniciador | Ação | Consulta informações da transferência |
19 | Iniciador | Comunicação | Notifica usuário contratante do sucesso na transferência |
20 | Iniciador | Comunicação | Notifica PSP recebedor do sucesso na transferência de fundos |
21 | Usuário contratante | Comunicação | Recebe notificação de sucesso na transferência |
22 | PSP Recebedor | Comunicação | Recebe notificação de sucesso na transferência |
Entraremos em detalhes sobre alguns passos mencionado e o comportamento esperado pelos agentes envolvidos na transação
...