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.
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 |
|---|---|---|
Casos de uso | 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 |
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, 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
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:
4.1.2 - Possibilidade de edição de consentimentos de longa duração para o Pix Automático
Instruções recebidas na consulta pública do Pix Automático deixaram claro a necessidade de permissão da edição de alguns parâmetros do consentimento tanto no ambiente do iniciador quanto no ambiente do PSP Pagador. A edição deverá ser feita via endpoint PATCH /recurring-consents/{recurringConsentId}. As regras para edição podem ser encontradas na descrição do endpoint. Atentem que os campos que permitem edição poderão ser modificados a qualquer hora, sem a necessidade de versionamento da API, cabendo a cada instituições acompanhar a página referenciada também na descrição do endpoint PATCH /recurring-consents/{recurringConsentId}.
4.1.3 - Sobre rejeição e revogação de consentimentos de longa duração.
Existem algumas pequenas divergências de regras na revogação e rejeição do consentimento de longa duração entre os produtos Pix Automático e Transferências Inteligentes, vamos trazer primeiro os motivos de rejeição que possuem particularidades entre os produtos e explicar como trata-los.
SALDO_INSUFICIENTE: Quando criado um consentimento de longa duração para o Pix Automático, é possível que o recebedor tenha estipulado um pagamento imediato para ocorrer neste consentimento. Sendo assim, apenas para este produto(Pix Automático) e no cenário do usuário não possuir saldo para o pagamento imediato, este erro poderá ser retornado. Consentimentos de longa duração criados para Transferências Inteligentes não possuem essa característica de cobranças imediatas declaradas no consentimento, portanto não há como fazer essa validação.
VALOR_ACIMA_LIMITE: O comportamento é semelhante ao do erro anterior (SALDO_INSUFICIENTE). Pela regra do arranjo do Pix Automático, o limite definido pelo usuário pagador no PSP do pagador (que sempre estará habilitado para uso) em uma solicitação de criação de consentimento de longa duração. Caso exista um pagamento imediato, e essa solicitação de pagamento ultrapassa algum dos limites definidos pelo usuário, este erro deverá ser retornado. Transferências Inteligentes não possui essa validação para o consentimento, uma vez que não há declaração imediata de cobrança.
Os outros motivos de rejeição, tanto síncronos como assíncronos do consentimento de longa duração, seguem o mesmo comportamento para ambos os produtos e não necessitam de maiores explicações.
Tratando agora dos motivos de revogação, uma regra comum para ambos os produtos (Pix Automático e Transferências Inteligentes) é que para um consentimento de longa duração ser revogado, primeiro ele precisou ser aprovado. Apenas consentimentos no status “AUTHORISED”, independente do produto, são passíveis de revogação, vamos trazer os motivos de revogação e como eles se aplicam para cada produto.
REVOGADO_RECEBEDOR: Aplicável apenas para o produto Pix Automático, uma vez que o recebedor pode solicitar, via Iniciador, a revogação de um consentimento. Um exemplo seria o termino de um contrato de streaming, onde o provedor do serviço de streaming (recebedor) poderia solicitar a revogação quando o usuário logado em algum de seus canais solicitar o cancelamento do serviço. Como Transferências Inteligentes caracteriza uma transferência de fundos de mesma titularidade, não há a figura do recebedor, apenas do usuário(que também pode ser considerado o recebedor), portanto tal motivo de revogação não se aplica.
REVOGADO_USUARIO: Aplicável para ambos os produtos, porém com pequena particularidade para o produto Pix Automático. Por definição, todas as solicitações de cobrança no Pix Automático precisam ser agendadas com 2 a 10 dias de antecedência e o usuário pagador pode cancelar qualquer pagamento agendado na sua conta até as 23h59 do dia anterior ao dia definido para liquidação. Sendo assim, caso um usuário solicite a revogação um consentimento e este possua um pagamento associado já agendado para ocorrer, deve-se então validar a data de solicitação da revogação e a data de liquidação do pagamento. Caso a data de revogação do consentimento seja a mesma de liquidação do pagamento, o pagamento será liquidado normalmente e o consentimento de longa duração será revogado, não permitindo novos agendamentos de cobrança.
NAO_INFORMADO: Deve ser utilizado para motivos de revogação que envolvam informações que não devem ser compartilhadas no ecossistema por respeito a privacidade do usuário. Ex: Suspeita de Fraude, Bloqueio Judicial.
4.2 - Processo de liquidação
Apesar de ambos os produtos utilizarem-se dos mesmos endpoints, tanto para criação do consentimento quanto para a liquidação de um pagamento, as regras aplicadas a cada um deles são diferentes. Neste capítulo, veremos como fica o fluxo de liquidação para os casos de uso apresentados anteriormente.
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 de Transferências Inteligentes
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