Comparação de Páginas

...

1 - Histórico de versionamento

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.

2 - Introdução

Bem-vindo ao guia do Pix Automático e Transferências Inteligentes e Sweeping Accounts, 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.

...

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.

Sweeping AccountsTransferências Inteligentes:

No universo do Open Finance Brasil, a funcionalidade de Sweeping Accounts 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 permite a transferência automática de fundos excedentes de contas com saldo positivo para uma conta central, com ou sem prazo definido, proporcionando uma solução eficaz para a concentração de fundos e a redução de custos associados.

Ao explorar este guia, você terá uma visão detalhada das funcionalidades de Pagamentos Automáticos e Sweeping AccountsTransferê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	Sweeping AccountsTransferê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	Sweeping accounts 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 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 Transferências Inteligentes.	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

4 - Descrição da usabilidade para Transferências Inteligentes

...

4.1- Adesão aos produtos

Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, o Transferências Inteligentes 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 Transferências Inteligentes 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.

...

Expandir

title	12 - "Cria o consentimento (POST /recurring-consents)"

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 Sweeping Accounts 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 o Sweeping AccountsTransferê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:

Bloco de código

{
    "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",
            "accountType": "CACC"
        },
        "recurringConfiguration": {
            "automatic": {
                "contractId": "YZXYZ000323002893",
                "transactionLimit": "100.00",
                "period": "MENSAL",
                "dayOfMonth": 22,
                "contractDebtor": {
                    "name": "Policarpo Quaresma",
                    "document": {
                        "identification": "41331654000185",
                        "rel": "CNPJ"
                    }
                },
                "immediatePayment": {
                    "type": "PIX",
                    "date": "2023-09-22",
                    "currency": "BRL",
                    "amount": "50.00",
                    "creditorAccount": {
                        "ispb": "12345678",
                        "issuer": "1774",
                        "number": "1234567890",
                        "accountType": "CACC"
                    }
                }
            }
        }
    }
}

Informações
Notem que: O objeto `"recurringConfiguration"` recebeu as informações necessárias exclusivamente para o Transferências Inteligentes.

Considerem agora o caso de uso mencionado para o Sweeping AccountsTransferências Inteligentes, o investimento inteligente, onde o usuário, mensalmente, envia uma transferência entre diferentes instituições para realização de investimentos.

Como no caso de uso anterior, precisamos definir algumas regras para entendermos a aplicação;

O investimento ocorrerá semanalmente, todas as quinta-feiras, a partir do dia 22/09/2023;
O valor de investimento fixo foi definido como R$150,00, observem no payload abaixo que este valor não aparece em canto nenhum, isto se dá devido ao fato do campo “/data/recurringConfiguration/sweeping/amount" ser o valor máximo total permitido para ser transacionado via este consentimento, enquanto o campo "/data/recurringConfiguration/sweeping/transactionLimit" representa o limite máximo por transação, independente de qualquer limite periódico, sendo os outros campos de "transactionLimit", pertencentes ao objeto "periodicLimits", abaixo do "/data/recurringConfiguration/sweeping/transactionLimit" em ordem de validação.
Podem ocorrer ofertas de investimentos que aumentem o valor investido durante o mês, por isso o usuário definiu um limite de R$1000,00;
Para facilitar a gestão de quantos investimentos ele tem, o usuário decidiu que, por mês, ele vai fazer no máximo dez investimentos;
O usuário também definiu que esse investimento em um ano, valor total investido por ele chegue até a R$5000,00.

A duração do consentimento, ou seja, sua data de expiração (que também foi definida pelo usuário) é de um ano.

Bloco de código

{
    "data": {
        "loggedUser": {
            "document": {
                "identification": "20162457000",
                "rel": "CPF"
            }
        },
        "creditors": [
            {
                "personType": "PESSOA_FISICA",
                "cpfCnpj": "20162457000",
                "name": "Benjamin Constant"
            }
        ],
        "startDateTime": "2023-09-22",
        "expirationDateTime": "2024-09-21",
        "additionalInformation": "Minha recorrência",
        "debtorAccount": {
            "ispb": "12345678",
            "issuer": "1774",
            "number": "1234567890",
            "accountType": "CACC"
        },
        "recurringConfiguration": {
            "sweeping": {
                "periodicLimits": {
                    "day":{
                        "quantityLimit": 2,
                        "transactionLimit": "500.00"
                    },
                    "month":{
                        "quantityLimit": 10,
                        "transactionLimit": "1000.00"
                    },
                    "year": {
                        "transactionLimit": "5000.00"
                    }
                }
            }
        }
    }
}

Nota

Importante:

Como podem observar, temos um campo do tipo array presente na criação do consentimento, o “/data/creditors/". Para o o produto Transferências Inteligentes, não há a possibilidade de mais de um item nesse array, uma vez que este campo representa as contas que irão receber a transação, a cada consentimento, para o Transferências Inteligentes que pode possuir apenas uma conta como destino.
- Agora, quando falamos de Sweeping AccountsTransferências Inteligentes, esse campo pode ser preenchido com quantos itens forem necessários, de acordo com a solicitação do cliente de com quantas e quais contas ele deseja habilitar a funcionalidade. O Iniciador deverá solicitar ao usuário a lista de creditors accounts.
  - Usuários PJ podem cadastrar contas com CNPJ de mesma raiz (8 primeiros dígitos do CNPJ), como em casos de empresas com matriz e filial
    - O PSP pagador deverá validar se os CNPJs que constam no payload possuem a mesma raiz e as permissões necessárias para fazer as movimentações.

Se uma instituição desejar implementar algum caso de uso que precise da informação de saldo de contas do usuário em outra(s) instituição(ões), como por exemplo, cobertura automática de saldo negativo via API de pagamentos automáticos (Ex. aplicativos de gestão financeira pessoal - PFM), precisa também de um consentimento de fase 2 (Dados do cliente), o qual permite a consulta do saldo pela instituição. O consentimento de longa duração exclusivo de fase 3 (Serviços - Pagamentos) não da acesso a essa informação.

...

Expandir

title	27 - "Consulta status do consentimento"

Na situação onde o iniciador possui o mecanismo de Webhook, não há necessidade de realizar as consultas (GET /recurring-consents/{recurringConsentId}) durante esse passo, basta aguardar a notificação de alteração de status que virá do detentor e realizar uma única consulta já com a informação atualizada. Caso não possua Webhook, pode realizar o polling normalmente.
O atingimento de limites periódicos não move o consentimento para o status “CONSUMED”, apenas impede que outra transação ocorra dentro do período estipulado no preenchimento dos campos. Os casos que movem o consentimento para “CONSUMED” são:
- Ele ter chego na sua data de expiração;
- Atingir o valor definido no campo “/data/recurringConfiguration/sweeping/amount";
Para minimizar os riscos para usuário, ao utilizar o produto “Sweeping Accounts” “Transferências Inteligentes” é imprescindível que o usuário defina ao menos um dos limites, seja limite global de valor total (“/data/recurringConfiguration/sweeping/amount"), limite de valor máximo por transação ("/data/recurringConfiguration/sweeping/transactionLimit") ou periódico ("/data/recurringConfiguration/sweeping/periodicLimits"). A necessidade se justifica pelo falo do “Sweeping Accounts” “Transferências Inteligentes” caracterizar uma transferência instantânea de fundos, o que pode acarretar em diversos problemas de segurança e alguns desses podem ser mitigados por essa ação.

4.1.2 - Possibilidade de edição de consentimentos de longa duração para o Transferências Inteligentes

Instruções recebidas na consulta pública do Transferências Inteligentes 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 Transferências Inteligentes e Sweeping Accounts, 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 Transferências Inteligentes, é possível que o recebedor tenha estipulado um pagamento imediato para ocorrer neste consentimento. Sendo assim, apenas para este produto(Transferências Inteligentes) 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 o Sweeping Accounts 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 Transferências Inteligentes, 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. Sweeping Accounts 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 (Transferências Inteligentes e Sweeping Accounts) é 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 Transferências Inteligentes, 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 o Sweeping Accounts 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 Transferências Inteligentes. Por definição, todas as solicitações de cobrança no Transferências Inteligentes 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 Transferências Inteligentes

...

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.

...

Expandir

title	21 - "Consulta informações do pagamento"

O iniciador, com posse do recurringPaymentId, precisa consultar o PSP do pagador, via polling e no endpoint GET /pix/recurring-payments/{recurringPaymentId}, o status da sua solicitação. Caso seja um pagamento imediato necessário à consolidação de um contrato, deve realizar a consulta até o atingimento do status final da liquidação, ACSC, confirmando assim a finalização da transação.
Para pagamentos automáticos agendados, deve-se consultar até que o mesmo possua o status SCHD.
Caso ocorra algum erro dentro do PSP Pagador durante o processamento da liquidação, também pode ser recuperado via chamada ao endpoint supracitado.
Caso o iniciador queria consultar todos os pagamentos associados a um consentimento de longa duração específico, pode fazer via endpoint GET /pix/recurring-payments, onde precisa passar um parâmetro do tipo query, o recurringConsentId, além de poder especificar períodos específicos de cobranças através dos campos startDate e endDate, também passados como parâmetros do tipo query.
Caso o Iniciador possua implementado o mecanismo de Webhook, não há necessidade de realizar consultas periódicas no PSP do pagador (polling) para verificar o status do pagamento, basta aguardar a notificação via Webhook e realizar a consulta para verificar as alterações.

4.2.2- Fluxo de liquidação do

...

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

...

Versões comparadas

Versão antiga 6

Nova versão 7

Chave

1 - Histórico de versionamento

2 - Introdução

3 - Regras de negócios para Pagamentos Automáticos e

Transferências Inteligentes

Legenda

4 - Descrição da usabilidade para Transferências Inteligentes

4.1- Adesão aos produtos

4.1.1 - Fluxo da adesão

4.1.2 - Possibilidade de edição de consentimentos de longa duração para o Transferências Inteligentes

4.1.3 - Sobre rejeição e revogação de consentimentos de longa duração.

4.2 - Processo de liquidação

4.2.1 - Fluxo para liquidação do Transferências Inteligentes

4.2.2- Fluxo de liquidação do

Transferências Inteligentes

Comparação de Páginas

Versões comparadas

Versão antiga 6

Nova versão 7

Chave

<span class="diff-html-changed" data-a11y-before="Start of changed content" data-a11y-after="End of changed content" id="changed-diff-0">[data-colorid=</span>

2 - Introdução

3 - Regras de negócios para Pagamentos Automáticos e

Transferências Inteligentes

Legenda

4 - Descrição da usabilidade para Transferências Inteligentes

4.1- Adesão aos produtos

4.1.1 - Fluxo da adesão

4.1.2 - Possibilidade de edição de consentimentos de longa duração para o Transferências Inteligentes

4.1.3 - Sobre rejeição e revogação de consentimentos de longa duração.

4.2 - Processo de liquidação

4.2.1 - Fluxo para liquidação do Transferências Inteligentes

4.2.2- Fluxo de liquidação do

Transferências Inteligentes