Comparação de Páginas

1 - Histórico de versionamento

...

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
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

...

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:

...

Expandir

title	15 - "Processa solicitação de consentimento de longa duração"

A partir do sucesso da chamada deste passo, iniciam-se as validações assíncronas do consentimento.
Detentor precisa realizar as validações assíncronas levando em consideração os momentos descritos no quadro abaixo.

Etapa Fluxograma do Pagamento Automático	Erros possíveis	Observações sobre os erros
Redireciona usuário para aplicação do detentor	FALHA_INFRAESTRUTURA	Ocorreu um problema na infraestrutura interna do Detentor
	NAO_INFORMADO	Validações internas realizadas pelo Detentor (ex. análise de fraudes)
	TEMPO_EXPIRADO_AUTORIZACAO	Usuário não concluiu a autorização do consentimento
Realiza Autenticação	FALHA_INFRAESTRUTURA	Ocorreu um problema na infraestrutura interna do Detentor
	TEMPO_EXPIRADO_AUTORIZACAO	Usuário não concluiu a autorização do consentimento
	REJEITADO_USUARIO	Usuário, enquanto visualizava a tela de autenticação, resolveu cancelar a transação.
	NAO_INFORMADO	Validações internas realizadas pelo Detentor (ex. análise de fraudes)
Autoriza o consentimento	FALHA_INFRAESTRUTURA	Ocorreu um problema na infraestrutura interna do Detentor
	CONTAS_ORIGEM_DESTINO_IGUAIS	As contas definidas como recebedora e pagadora são as mesmas
	CONTA_NAO_PERMITE_PAGAMENTO	O tipo de conta recebedora não permite o crédito do pagamento.
	SALDO_INSUFICIENTE	Caso exista um pagamento imediato declarado na criação do consentimento e o mesmo não possa ocorrer por falta de saldo
	VALOR_ACIMA_LIMITE	Caso exista um pagamento imediato declarado na criação do consentimento e o mesmo não possa ocorrer por exceder o limite definido pelo usuário na instituição, no arranjo ou qualquer outro considerado pelo Detentor
	REJEITADO_USUARIO	O usuário, na tela de autorização do consentimento, não o autorizou.
	VALOR_INVALIDO	O valor enviado pelo Iniciador não é válido para o pagamento solicitado.
	NAO_INFORMADO	Validações internas realizadas pelo Detentor (ex. análise de fraudes)
Retorna access_token	FALHA_INFRAESTRUTURA	Ocorreu um problema na infraestrutura interna do Detentor
	TEMPO_EXPIRADO_CONSUMO	Iniciador não concluiu o pagamento com consentimento aprovado
	NAO_INFORMADO	Validações internas realizadas pelo Detentor (ex. análise de fraudes)

A instituição Detentora precisa estar atenta durante o processamento da solicitação de consentimento referente a presença do objeto “/data/recurringConfiguration/automatic/immediatePayment”. Caso esse campo esteja preenchido, o detentor deverá, em momento posterior a criação do consentimento permitir uma solicitação de pagamento imediata que siga os parâmetros definidos dentro do objeto.
Serviços dessa natureza, geralmente exigem esse pagamento para que a assinatura seja válida. Para não gerar inconsistência entre consentimentos de longa duração aprovados e quais realmente estarão em uso, caso um consentimento de longa duração possua, na sua criação, uma declaração de pagamento imediato e o cliente não possuir saldo ou limite no momento da adesão, o PSP do pagador deve rejeitar assincronamente o consentimento e utilizar o “rejection/reason/code" cabível:
- Caso o cliente tenha limite habilitado na conta selecionada mas o valor cobrado seja superior ao limite disponível, preencher o “rejection/reason/code" com VALOR_ACIMA_LIMITE;
- Caso o cliente não tenha limite e o saldo disponível em conta não é suficiente, preencher o “rejection/reason/code" com o valor SALDO_INSUFICIENTE.

...

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:

Expandir

title	12 - "Cria solicitação de pagamento"

Sobre o access_token que será utilizado na iniciação de pagamentos para o Pix Automático. Temos basicamente dois cenários possíveis:
- Primeiro caso: Considerado o mais simples, onde o iniciador possui um authorization_code ainda válido, recebido durante o processo de adesão, o qual poderá utilizar para trocar por um access_token e realizar a transação.
- Segundo caso: O iniciador está agendando uma transação quando o access_token da adesão não é mais válido. Nesse cenário, o iniciador deve antes de criar uma solicitação de pagamento, realizar uma solicitação de refresh_token ao PSP do pagador. Informações sobre o mecanismo de refresh_token podem ser encontrados em [PT] Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3 - 7.1. Mecanismo de Autorização.

Considerando o primeiro caso de uso, “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”:

Uma vez que há a presença do pagamento imediato, o iniciador pode gerar imediatamente uma cobrança na conta do usuário no PSP Pagador.
Após 30 dias da adesão, ocorre novamente uma cobrança. A data dessa cobrança precisa ser agendada seguindo a regra do arranjo do Pix Automático, ou seja, 2 a 10 dias antes da sua data de liquidação o recebedor deve enviar a cobrança ao Iniciador, que por sua vez encaminha ao PSP do pagador. Além disso, temos mais algumas regras que são necessárias, sendo elas:
- A geração do endToEndId deve seguir a data de cadastro do usuário no PSP pagador. O campo “/data/ibgeTownCode “ será retornado obrigatoriamente na consulta do consentimento de longa duração(GET /recurring-consents/{recurringConsentId}) quando o consentimento estiver com status "AUTHORISED".
- Para o Pix Automático, pagamentos podem ocorrer apenas em dias úteis. Caso a data de liquidação caia em um dia que não seja considerado dia útil, o pagamento deve ser agendado para ocorrer no dia útil mais próximo, assim como o endToEndId também precisa ser ajustado para esse dia.
- Pagamentos imediatos declarados na criação do consentimento de longa duração podem ocorrer via canal primário e em qualquer horário.

Uma vez que o recebedor exigiu uma cobrança imediata e o usuário autorizou essa cobrança, o iniciador precisa enviar o payload de pagamento:

Bloco de código

{
    "data": {
        "endToEndId": "E9040088820210128000800123873170",
        "date": "2023-09-22",
        "payment": {
            "amount": "50.00",
            "currency": "BRL"
        },
        "creditorAccount": {
            "ispb": "12345678",
            "issuer": "1774",
            "number": "1234567890",
            "accountType": "CACC"
        },
        "remittanceInformation": "Pagamento da nota XPTO035-002.",
        "cnpjInitiator": "50685362000135",
        "ibgeTownCode": "5300108",
        "authorisationFlow": "HYBRID_FLOW"
    }
}

As cobranças subsequentes, como já mencionado, devem ocorrer entre 2 a 10 dias antes da data de liquidação.
Caso exista a necessidade de enviar a solicitação de cobrança imediata e uma solicitação de cobrança agendada, para o mesmo consentimento de longa duração, devem ser feitas duas chamadas a API de pagamentos automáticos, no endpoint POST /pix/recurring-payments, a primeira para o pagamento imediato, seguida de uma segunda requisição responsável por realizar o agendamento da cobrança na data especificada e seguindo todas as regras já mencionadas até aqui.

...

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

...

Expandir

title	10 - "Cria solicitação de transferência"

Sobre o access_token que será utilizado na iniciação de pagamentos para Transferências Inteligentes. Temos basicamente dois cenários possíveis:
- Primeiro caso: Considerado o mais simples, onde o iniciador possui um authorization_code ainda válido, recebido durante o processo de adesão, o qual poderá utilizar para trocar por um access_token e realizar a transação.
- Segundo caso: O iniciador está agendando uma transação quando o access_token da adesão não é mais válido. Nesse cenário, o iniciador deve antes de criar uma solicitação de pagamento, realizar uma solicitação de refresh_token ao PSP do pagador. Informações sobre o mecanismo de refresh_token podem ser encontrados em [PT] Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3 - 7.1. Mecanismo de Autorização.
Sinais de risco:
- Por se tratar de uma transferência automática entre instituições, por mais que exista a checagem de titularidade, entende-se que mais algumas informações podem ser necessárias para autorizar ou não a iniciação de pagamentos automáticos. A API de pagamentos automáticos, como o próprio nome deixa claro, poderá comandar solicitações de pagamento e transferências entre instituições de maneira automática, ou seja, pode ou não estar na presença do usuário. A API de pagamentos automáticos hoje possui, devido a necessidade do arranjo Pix, o mecanismo de temporização no qual as instituições utilizam para poder realizar algumas validações de antifraude, podendo o PSP do pagador aprovar ou negar a solicitação de pagamento advinda do iniciador.
- Para minimizar os riscos, foi colocado dentro do POST /pix/recurring-payments um objeto para receber informações sobre o usuário, seu dispositivo e sua conexão, aqui chamados de Sinais de risco.
- O objeto que contem os sinais de risco é o “/data/riskSignals", sendo os sinais de risco divididos em duas categorias, uma representa o usuário online no ambiente do iniciador (o que será indicado pela preenchimento do objeto "/data/riskSignals/manual" e seus campos) ou sem a presença do usuário no ambiente do iniciador (indicado pelo preenchimento do objeto "/data/riskSignals/automatic" e seus campos).
Transferências automáticas entre contas de mesma titularidade podem ocorrer todos os dias da semana, em qualquer horário, devem ser liquidadas via canal primário e seguir as regras do arranjo.

Para o caso de uso que estamos tratando aqui, na primeira quinta-feira após o dia 22/09/2023, o iniciador deverá enviar uma requisição de pagamento automático (POST /pix/recurring-payments), contendo a primeira solicitação de transferência, assim como definido pelo usuário e sem a presença dele:

Bloco de código

{
    "data": {
        "endToEndId": "E9040088820210128000800123873170",
        "date": "2023-09-28",
        "payment": {
            "amount": "150.00",
            "currency": "BRL"
        },
        "creditorAccount": {
            "ispb": "12345678",
            "issuer": "1774",
            "number": "1234567890",
            "accountType": "CACC"
        },
        "remittanceInformation": "Pagamento da nota XPTO035-002.",
        "cnpjInitiator": "50685362000135",
        "ibgeTownCode": "5300108",
        "authorisationFlow": "HYBRID_FLOW",
        "riskSignals": {
          "automatic": {
            "lastLoginDateTime": "2023-10-09T08:15:00Z",
            "pixKeyRegistrationDateTime": "2023-10-09T08:20:00Z
          }
        }
    }
}

Agora, vamos fazer uma conta simples, se o usuário autorizou R$ 150,00 por semana, em 4 semanas são R$ 600,00. Após 33 semanas apenas de movimentações planejadas, sem nenhum investimento inteligente, teremos então um total de R$ 4.950,00 investidos, muito próximo do valor total especificado pelo usuário no momento de consentimento, que é de R$ 5.000,00 por ano. Sendo assim, o PSP Pagador (Detentor), na 34ª solicitação irá retornar um erro para o iniciador, informando que o limite definido pelo usuário foi atingindo.
Um outro limite possível de ser atingido é o limite de quantidades de transações, que por sua vez também é definido pelo usuário. No nosso exemplo, quando criamos o consentimento, definimos o limite de quantidade de investimentos por dia em 2, ou seja, a partir da terceira tentativa de investimento no mesmo dia, que esteja dentro do valor total permitido também por dia (R$ 500,00), um erro também será retornado.
Abaixo temos dois possíveis erros relacionados aos limites acima citados, são eles:
- LIMITE_PERIODO_VALOR_EXCEDIDO: É o erro aplicável no primeiro exemplo citado. Uma vez que a transação seria negada porque o limite que foi atingido foi o limite anual de valor definido pelo usuário (campo “/data/recurringConfiguration/sweeping/periodicLimits/year/amount" preenchido na criação do consentimento), impossibilitando novas transações. Importante salientar que, caso o Iniciador, ao invés de tentar fazer o valor de investimento com o valor predefinido pelo usuário fosse fazer um investimento inteligente, também consentido pelo usuário, no valor de R$ 50,00, seria aceito normalmente, pois não passaria o valor máximo definido para o período (1 ano).
- LIMITE_PERIODO_QUANTIDADE_EXCEDIDO: É o erro aplicável ao segundo exemplo. A transação seria negada não por ter atingindo uma quantidade pré definida de valores, mais sim uma quantidade pre definida de investimentos realizados em um determinado periodo definido pelo usuário (campo “/data/recurringConfiguration/sweeping/periodicLimits/day/quantityLimit" preenchido na criação do consentimento). Se o Iniciador tentar novamente no próximo dia e caso essa seja a única regra que estava impedindo-o de realizar a transferência, a transferência poderá ser realizada.

...

Expandir

title	18 - "Consulta informações da transferência"

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. Deve realizar a consulta até o atingimento do status final da liquidação, ACSC (caso tenha sido completada com sucesso) ou RJCT (caso tenha ocorrido algum problema na liquidação), confirmando assim a finalização da transação.
Caso ocorra algum erro dentro do PSP Pagador durante o processamento da liquidação, também pode ser recuperado via chamada ao endpoint citado acima, observando os motivos de rejeição.
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.

5 - Fluxo de tentativa Intradia e Extradia para o produto Pix automático na API Pagamentos automáticos

Conceito geral do fluxo de tentativas Intradia e Extradia para o produto Pix automático
- Fluxo Intradia - A transação ocorre no dia em que foi solicitada a sua programação
  - Primeira Tentativa: A liquidação da transação é tentada entre 0h e 8h no dia programado
  - Segunda Tentativa: Se a ordem de pagamento não for liquidada até às 8h, o PSP (prestador de serviços de pagamento) do pagador deve realizar uma nova tentativa entre 18h e 21h do mesmo dia
  - Na situação de falha onde o e2eid não pode ser mais utilizado a iniciadora deve enviar um novo pagamento contendo um novo e2eid (Falha de infra SPI e/ou PSP recebedor)
- Fluxo Extradia - A transação é programada para ocorrer em uma data futura, com processamento e liquidação automática nessa data
  - O iniciador a pedido do recebedor pode realizar as novas tentativas
  - Quando um pagamento não é liquidado na data programada (Intradia), a detentora pode realizar novas tentativas dentro de uma janela de 7 dias corridos após a data original de liquidação, por meio de acionamento do iniciador para detentora, até às 23:59h do dia imediatamente anterior à liquidação
  - Durante esse período de sete dias o iniciador pode fazer até três tentativas de liquidação em datas diferentes, seguindo as mesmas regras de prazos da intradia

Exemplo de aplicabilidade

Image Added

Data envio: 14/09/24 – (02 a 10 dias de antecedência da liquidação)
- Data liquidação: 16 de setembro de 2024.
A primeira tentativa (Intradia):
- Data liquidação: 16 de setembro de 2024
  - Primeira Tentativa: A liquidação é tentada entre 0h e 8h.
    - Se houver saldo suficiente e os limites forem respeitados, a transação é concluída.
    - Caso falhe (por exemplo, por saldo insuficiente), segue-se para as novas tentativas.
  - Segunda Tentativa: Uma nova tentativa é feita entre 18h e 21h.
    - Se houver saldo suficiente e os limites forem respeitados, a transação é concluída
    - Em caso de falha considerar o cenário de tentativas (Extradias)

Image Added

Novas tentativas nos 7 dias seguintes (Extradias):
- Se a liquidação não for concluída no dia 16 de setembro, o detentor pode tentar realizar novas liquidações durante os próximos 7 dias corridos, através do acionamento do iniciador em até 3 tentativas em dias diferentes.
- Primeira Tentativa Extradias: 18 de setembro de 2024
  - A primeira tentativa após a falha no dia 16 pode ser feita.
    - A liquidação é tentada novamente dentro das janelas de liquidação.
  - Segunda Tentativa Extradias: 20 de setembro de 2024
    - Se a tentativa do dia 18 falhar, o iniciador pode realizar uma nova tentativa
  - Terceira Tentativa Extradias: 22 de setembro de 2024, é feita no dentro do período de 7 dias corridos.
    - Se houver saldo suficiente e os limites forem respeitados, a transação é concluída
    - Em caso de falha notificar o motivo

Versões comparadas

Versão antiga 20

Nova versão Atual

Chave

1 - Histórico de versionamento

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

Legenda

4.1.1 - Fluxo da adesão

4.2.1 - Fluxo para liquidação do Pix Automático

4.2.2- Fluxo de liquidação de Transferências Inteligentes

5 - Fluxo de tentativa Intradia e Extradia para o produto Pix automático na API Pagamentos automáticos