Pix Automático - Guia para versão 2.1.0 e anteriores
1 - Introdução
1.1 - Sobre o documento
Este guia auxiliará os implementadores a compreenderem as funcionalidades de criação do consentimento com pagamento de adesão ou sem no momento da contratação do serviço. Para o processo de liquidação dos pagamentos, abordaremos o funcionamento da primeira ordem de pagamento de um ciclo de cobrança, das tentativas no mesmo dia e das tentativas em dias subsequentes. Além disso, também temos as regras de negócio que compõe o produto no âmbito do Open Finance.
Não é o objetivo que a leitura deste documento substitua a leitura de outros documentos de igual importância. Recomendamos a leitura de todos os documentos relacionados para permitir o correto entendimento sobre a operação deste produto. Alguns exemplos de documentos importantes:
Normativo/Manual/Documento | Tema |
|---|---|
Dispõe sobre a implementação do Open Finance. | |
Dispõe sobre os limites de valor para as transações no âmbito do Pix. | |
Estabelece os procedimentos operacionais relativos ao Pix Automático. | |
Dispõe sobre procedimentos técnicos e operacionais aos quais as instituições devem adotar (Inclui orientações para reportes à PCM, o Guia De Experiencia, entre outros). |
1.2 - Pix Automático
É uma solução que permite o recebedor solicitar o pagamento de cobranças recorrentes de maneira automatizada. Isso ocorre após o usuário pagador conceder permissão ao recebedor, no contexto do serviço contratado. A funcionalidade possibilita que o recebedor PJ, através de seu PSI, envie regularmente os detalhes das cobranças recorrentes ao PSP do Pagador (dentro de uma periodicidade previamente definida) este, por sua vez, agenda o débito e efetua a liquidação automaticamente na data programada, conforme o contrato de serviços estabelecido entre usuário pagador e recebedor. A implementação do Pix Automático é obrigatória para as detentoras que atendem clientes PF e PJ, porém, instituições que atendem apenas clientes PJ ou que não desejem ofertar o produto para o público PJ, podem realizar o optout junto ao BCB, conforme especificado na IN BCB 581, de 30/12/2024.
Essa funcionalidade está presente na API de pagamentos automáticos, a partir de sua versão 2.0.0. O link para a API pode ser encontrado abaixo.
2 - Regras para Pix Automático no OFB
2.1 - Regras de negócio:
No quadro abaixo podemos observar as regras de negócio definidas para o produto Pix Automático no âmbito do Open Finance.
Cenários | Pix Automático |
|---|---|
Casos de uso | Utilities/serviços públicos, assinaturas, escolas, academias, aluguel, seguros, cobranças de pagamento de operação de crédito |
Configurações de recorrência |
|
Motor de recorrência | Criação de um consentimento para recorrência com limites de valores e prazos, e definição de periodicidade |
Valor | Fixo ou variável |
Modelo de recorrência, intervalos de pagamentos | Semanal, mensal, trimestral, semestral e anual |
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 |
Comanda o pagamento | Iniciador |
Recebedor | PJ |
Primeiro pagamento | Imediato ou Agendado |
Demais pagamentos | Agendado |
Permite pagamentos imediatos | Sim, para adesão |
Definição do final do período da recorrência | Opcional |
Prazo máximo de duração para recorrência do consentimento | Opcional |
Permite a configurar data de início do consentimento? | Sim |
Permite a configurar data de expiração do consentimento? | Sim |
Permite limites globais do consentimento?¹ | Não |
Permite limites periódicos por consentimento? | Sim, uma transação liquidada com sucesso por período de recorrência. |
Permite limites por transação? | Sim. Recebedor pode definir valor mínimo. Pagador pode definir um valor máximo. O valor definido pelo Pagador não pode ser menor que o valor definido pelo Recebedor. |
Processo de adesão |
|
Fluxo de adesão | Consentimento FAPI long-lived tokens |
Role no diretório | CONTA, PAGTO |
Será possível editar configurações de recorrência no processo de adesão no Detentor? | Não |
Cancelamento do fluxo da adesão | Via Iniciador ou Detentor |
Permite múltiplas alçadas? | Sim |
Iniciador terá acesso aos status do processo de adesão via Webhook? | Sim |
Adesão tem id de contrato? | Sim |
Gestão de adesão |
|
Permite edição técnica dos dados do consentimento pós adesão²? | Sim, verificar no link |
Cancelamento da adesão | Pelo pagador, no ambiente da iniciadora ou detentora. Recebedor pode acionar o Iniciador para o cancelamento. |
Revogação da adesão | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude |
Consumação³ da adesão? | Detentor, apenas para recorrências com data de expiração definidas. |
Processo de liquidação |
|
Canal para liquidação | Serão utilizados os canais primário e secundário (obedecendo as regras da trilha Pix). Quem deverá criar o E2EID com a data da liquidação é o Iniciador. |
Dispara o pagamento⁴ | Detentor |
Onde o cliente cancela o pagamento? | Iniciadora ou Detentora |
Erros de saldo insuficiente modificam o status do consentimento? | Não, sendo o pagamento imediato (da adesão) ou agendado (da adesão ou recorrência). Diferente do arranjo Pix, onde, em algumas das jornadas, a falha no pagamento da adesão resulta no cancelamento da autorização |
Listagem das informações do pagamento | Busca por id do consentimento e por id de pagamento |
Iniciador é responsável pelo envio da ocorrência do pagamento? | Sim, no prazo de 2 a 10 dias anteriores a data de vencimento da cobrança |
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 |
Responsável pela geração do endToEndId | Iniciador |
Podem ocorrer liquidação em dias não úteis? | Sim, em casos em que a data de vencimento ocorra durante finais de semana, feriados e dias inexistentes(29, 30, 31), a data pode ser alterada, a critério do recebedor, para o dia útil seguinte. |
Qual é o localInstrument utilizado na liquidação? | MANU |
A data do primeiro pagamento (agendado ou imediata) da contratação do serviço (adesão) pode ser posterior ou igual à data do agendamento da primeira recorrência? | A data da primeira ocorrência de um pagamento associado a um ciclo de cobrança deve ser posterior a data de liquidação do pagamento da adesão ao serviço. Em outras palavras, só pode haver cobrança de recorrência após a data de liquidação da adesão. |
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. |
Tentativas para pagamentos que falharam
| Detentor realiza primeira tentativa das 0h – 8h. Segunda tentativa entre 18h – 21h. Caso de falha, recebedor pode solicitar ao iniciador envio de novas tentativas (contando que o pagador tenha aceito e o motivo do erro permita). Novas tentativas de liquidação devem ocorrer em até 7 dias corridos após a primeira tentativa. São permitidas no máximo 3 retentativas, totalizando 4 tentativas de liquidação para um mesmo pagamento. Iniciador deve informar ao detentor que o recebedor deseja ativar as retentativas, pagador deve autorizar em momento de consentimento. |
Funcionalidade de contestação | Contestação está disponível no arranjo Pix automático, conforme pode ser visto na Página 84, Requisito 4, Requisitos Mínimos para Experiencia do Usuário, versão 7.0 |
Legenda
1 - GT está avaliando se existe alguma normativa que obrigue uma das partes avisar ao pagador
2.2 Regras de notificação:
Notificações ao usuário pagador relacionadas ao consentimento (ou seja à permissão/autorização) devem, obrigatoriamente, ser enviadas pela ITP, não podendo ser desabilitadas pelo usuário.
É opcional para a detentora o envio dessas notificações, exceto nos casos relacionados a alteração de valor máximo e utilização do limite de crédito, quando também deverá obrigatoriamente notificar o cliente em caso de alteração.
Notificações ao usuário pagador relacionadas a agendamento e liquidação de pagamentos deverão estar habilitadas por padrão na detentora de conta, de acordo com o especificado nas regras do arranjo.
Apenas notificações de sucesso de agendamento poderão ser desabilitadas pelos usuários na detentora de conta. As demais permanecerão ativas, também seguindo o definido pelo arranjo.
O envio de notificações ao usuário pagador sobre agendamento e liquidações por parte da ITP é opcional. Se implementadas, deve ser permitido que possam ser desabilitadas pelo usuário.
A detentora de conta deverá comunicar todas as ocorrências de sucesso/não sucesso de agendamentos e pagamentos à ITP, para que esta avalie se deseja ou não notificar também o cliente.
A comunicação será realizada via Webhook e o ITP precisará consultar o recurso antes de realizar a avaliação.
É vedado à ITP o encaminhamento ao recebedor de mensagens de erro e motivos de rejeição que especifiquem que houve falha no pagamento por insuficiência de saldo ou de limites. Nesses casos, a comunicação ao recebedor sobre o não processamento do pagamento deve ser feita de modo genérico, com a orientação de que o usuário pagador busque informações em sua detentora de conta.
É vedado à ITP permitir ao recebedor o acesso a informações sobre valor máximo definido pelo cliente, bem como suas alterações.
3 - Descrição de fluxos
3.1- Para criação do consentimento:
Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, o Pix Automático possui consentimentos de longa duração, os quais poderão ter alguns parâmetros editados ao longo da sua vida útil. Entraremos mais no detalhe do processo de criação do consentimento a seguir.
3.1.1 - Jornada 1 - Fluxo da criação do consentimento sem pagamento de adesão
Serviços que não possuem pagamento de adesão são aqueles que, geralmente, paga-se pelo consumo, como serviços de energia elétrica, água e gás. Esta jornada trata desde a solicitação de autorização até a sua conclusã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 | 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. |
8 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor. |
9 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. |
10 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento recorrente. |
11 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. |
12 | Iniciador | Comunicação | Recebe o sucesso na criação do consentimento de longa duração e URL de redirecionamento. |
13 | Iniciador | Ação | Processa o retorno da solicitação de criação do consentimento de longa duração. |
14 | Iniciador | Comunicação | Redireciona o pagador para autenticação no Detentor. |
15 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Realiza a autenticação. |
16 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Autoriza o consentimento. |
17 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED. |
18 | 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. |
19 | Usuário Pagador | Comunicação | Em ambiente do PSP Pagador: PSP Pagador redireciona o usuário pagador para o ambiente do Iniciador. |
20 | Iniciador | Comunicação | Recebe informações do redirecionamento. |
21 | Iniciador | Ação | Valida informações recebidas. |
22 | Iniciador | Ação | Realiza consulta ao PSP do Pagador para verificar o estado do consentimento. AUTHORISED indica que o consentimento foi autorizado pelo cliente. Porém, caso a consulta retorne o valor REJECTED, deve-se abortar o processo de consentimento e pagador e recebedor devem ser comunicados da falha. |
23 | Iniciador | Comunicação | Notifica o pagador do resultado do processo de consentimento (do pagador ao serviço de cobranças recorrentes). |
24 | Pagador | Comunicação | Recebe notificação do resultado do processo de consentimento/autorização |
25 | Iniciador | Comunicação | Aguarda até que o(s) usuário pagador tenha realizado a aprovação do consentimento para notifica-lo do sucesso no processo de adesão. |
26 | Recebedor | Comunicação | Notifica o recebedor do resultado da adesão/consentimento |
3.1.2 - Jornada 2 - Fluxo da criação do consentimento com pagamento de adesão
A adesão ao serviço é considerado como o primeiro pagamento relacionado aquela contratação do serviço, em outras palavras, é o pagamento inicial para utilização de algum serviço contratado. Alguns exemplos de serviços que possuem essa característica são os de streaming, alugueis de bens e matrículas. Esta jornada trata desde a solicitação de autorização até a sua conclusã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 | 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. |
8 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor (POST /consents). |
9 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. |
10 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento de longa duração. |
11 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. |
12 | Iniciador | Comunicação |