Pix Automático e Transferências Inteligentes

1 - Histórico de versionamento

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.

2 - Introdução

Bem-vindo ao guia do Pix Automático e Transferências Inteligentes, exploraremos essas funcionalidades no cenário do Open Finance Brasil. Este guia destina-se a oferecer uma compreensão aprofundada de ambas as ferramentas, delineando como são implementadas no contexto do Open Finance Brasil e como podem transformar a maneira como usuários lidam com suas finanças.

Pagamentos Automáticos:

A funcionalidade de Pagamentos Automáticos foi projetada para simplificar a vida financeira, permitindo que o usuário agende débitos automáticos de serviços prestados por pessoas jurídicas. Seja o pagamento de contas de concessionárias de energia ou serviços de streaming, essa ferramenta oferece a conveniência de agendar pagamentos automáticos de forma flexível, mensal, semanal ou diária. Para clientes pessoa natural, o Pagamento Automático é obrigatório de ser ofertado, enquanto para pessoas jurídicas é opcional, proporcionando uma solução abrangente para suas necessidades de pagamento via Pix.

Transferências Inteligentes:

No universo do Open Finance Brasil, a funcionalidade de Transferências Inteligentes destaca-se como uma abordagem estratégica para a gestão inteligente de saldos em contas relacionadas. Seja para consumidores individuais ou empresas, essa ferramenta torna obrigatório aos detentores de conta oferecer uma solução que permita a transferência automática de fundos.

Ao explorar este guia, você terá uma visão detalhada das funcionalidades de Pagamentos Automáticos e Transferências Inteligentes, e como ambas podem aprimorar seus processos financeiros.

Essa funcionalidade está presente na API de pagamentos automáticos, a partir de sua versão 1.0.0. O link para a API pode ser encontrado abaixo.

Pagamentos automáticos

3 - Regras de negócios para Pagamentos Automáticos e Transferências Inteligentes

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	Transferências Inteligentes

	Pagamento Automático	Transferências Inteligentes
Casos de uso (Sugestões BC)	Utilities/serviços públicos, assinaturas, escolas, academias, aluguel, seguros, cobranças de pagamento de operação de crédito	Transferências Inteligentes 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	Não
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 (Seguir a utilização e regras do arranjo)
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. Se agendamento de cobrança, não.	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, INIC e MANU
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 - Conteúdo explicativo no header da API de pagamentos
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

4 - Descrição da usabilidade para Pix Automático e Transferências Inteligentes

4.1- Adesão aos produtos

Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, o Pix Automático e as Transferências Inteligentes 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

Imagem: BPMN com fluxo da adesão recorrentes do Pix Automático e Transferências Inteligentes

ID	CAMADA	TIPO	DESCRIÇÃ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 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:

Regras, restrições e orientações de preenchimento dos campos podem ser encontrados na especificação da API.

Diferentes produtos, mesma api, diferentes maneiras de utilizar

Pagamentos automáticos e Transferências Inteligentes (Assim como o VRP) vão utilizar o mesmo endpoint de criação de consentimentos de longa duração, o POST /recurring-consents;
O payload de criação do consentimento contém o objeto "recurringConfiguration", o qual atende ao conceito de oneOf, onde cada uma das possibilidades de preenchimento representam um produto e cada um dos produtos estarão associados a um único consentimento de longa duração;
Agora, pensando em casos de uso e em como utilizar o endpoint de criação de consentimentos de longa duração, vamos considerar dois casos de uso. O primeiro, para exemplificar o Pagamento Automático, é a adesão de um usuário a um serviço de assinatura de streaming qualquer. Já o segundo caso de uso que abordaremos aqui, para exemplificar Transferências Inteligentes, será o investimento inteligente, entraremos nos detalhes de cada um a seguir.

No exemplo de pagamento mensal de streaming via API de Pagamento automático onde o usuário aplica valor máximo de R$100,00 para o consentimento, precisamos antes definir alguns pontos, são eles:

Produtos dessa natureza comumente exigem um pagamento imediato para permitir o consumo do serviço pelo usuário Pagador imediatamente, caso o pagamento imediato seja necessário, o payload precisará ser preenchido de acordo, como veremos mais a frente. Abaixo, vamos descriminar algumas definições necessárias para o entendimento do preenchimento do payload.
- O valor base da assinatura será R$50,00.
  - Esse valor não é enviado na criação do consentimento de longa duração.
  - O campo “/data/recurringConfiguration/automatic/amount" representa que é um valor fixo de cobrança mensal.
  - O campo “/data/recurringConfiguration/automatic/transactionLimit" representa que é um valor de cobrança mensal com um limite máximo por cobrança definido pelo usuário.
- O cliente pode comprar produtos dentro da plataforma que aumentem o valor da cobrança, assim como mudar seu plano para valores maiores ou menores e continuar com seu consentimento válido;
- Há um pagamento imediato também no valor de R$ 50,00;
- O usuário determinou que o consentimento irá durar um ano, a partir da data de criação, aqui definida como por exemplo 22/09/2023;
- No payload abaixo, iremos exemplificar como ficaria a solicitação de criação de consentimento de longa duração que respeite esses critérios:
  - { "data": { "loggedUser": { "document": { "identification": "11111111111", "rel": "CPF" } }, "businessEntity": { "document": { "identification": "41331654000185", "rel": "CNPJ" } }, "creditors": [ { "personType": "PESSOA_JURIDICA", "cpfCnpj": "20162457000100", "name": "VideoFlix" } ], "startDateTime": "2023-09-22T08:30:00Z", "expirationDateTime": "2024-09-21T08:30:00Z", "additionalInformation": "Minha recorrência", "debtorAccount": { "ispb": "87654321", "issuer": "2885", "number": "56789012341"