...
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 pessoa naturais ou empresasjurídicas, essa ferramenta torna obrigatório aos API é de implementação obrigatório para os detentores de conta oferecer , oferecendo ao ecossistema uma solução que permita a transferência automática de fundos.
O produto 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.
2 - Regras de negócios para Transferências Inteligentes
...
| Transferências Inteligentes |
---|---|
Casos de uso | 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 |
Valor | Fixo ou variável |
Modelo de recorrência, intervalos de pagamentos | Restrito aos limites definidos no consentimento |
Gestão da Agenda | Iniciador |
Comanda o pagamento | Iniciador |
Recebedor | PN ou PJ de mesma titularidade |
Primeiro pagamento | Imediato |
Demais pagamentos | Imediato |
Permite pagamentos imediatos | Sim |
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 |
Permite limites por transação? | Sim |
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? | Não |
Gestão de adesão | |
Permite edição técnica dos dados do consentimento pós adesão²? | Não |
Cancelamento da recorrência | Pelo pagador, no ambiente da iniciadora ou detentora |
Revogação da recorrência | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude |
Consumação³ da recorrência? | Detentor |
Processo de liquidação | |
Canal para liquidação | Primário |
Dispara o pagamento⁴ | Iniciador |
Onde o cliente cancela o pagamento? | Não é possível |
Erros de saldo insuficiente modificam o status do consentimento? | Não |
Listagem das informações do pagamento | Busca por id do consentimento |
Iniciador é responsável pelo envio da ocorrência do pagamento? | Sim, imediatamente |
Quem avisa o pagador sobre pagamento com falha? | Iniciador |
Responsável pela geração do endToEndId | Iniciador |
A data agendada no consentimento e a data agendada do E2EID podem ser distintas? | Sim |
Qual é o localInstrument utilizado na liquidação? | DICT, INIC e MANU |
Outras informações | |
É possível habilitar crédito? | Sim - Conteúdo explicativo no header da API de pagamentos |
Retentativas
| Não |
Funcionalidade de contestação | MED |
...
3.1.1 - Jornada 1 - Autorização de consentimento
ID | CAMADA | TIPO | DESCRIÇÃO |
---|---|---|---|
1 | Pagador | Ação | No app do iniciador, seleciona as transferências inteligentes |
2 | Pagador | Ação | Informa a conta de débito que utilizará para as movimentações |
3 | Pagador | Comunicação | APP do iniciador envia os dados inseridos para o backend do iniciador |
4 | Iniciador | Comunicação | Recebe as informações inseridas no seu backend |
5 | Iniciador | Ação | Processa as informações recebidas |
6 | Iniciador | Ação | Prepara a solicitação para criação de consentimento no PSP Pagador selecionada pelo pagador |
7 | Iniciador | Comunicação | Envia a solicitação de consentimento para o PSP Pagador |
8 | PSP Pagador | Comunicação | Recebe a solicitação de um novo consentimento |
9 | PSP Pagador | Ação | Processa a solicitação de novo consentimento |
10 | PSP Pagador | Comunicação | Informa ao iniciador o sucesso na criação do consentimento |
11 | Iniciador | Comunicação | Recebe a resposta de sucesso na criação do consentimento |
12 | Iniciador | Ação | Prepara o redirecionamento do Pagador para o autenticação e autorização no ambiente do PSP Pagador |
13 | Iniciador | Comunicação | Redireciona o Pagador para autenticação e autorização |
14 | Pagador | Ação | Realiza a autenticação na instituição detentora |
15 | Pagador | Ação | Autoriza o consentimento. Nesta etapa, o Pagador pode selecionar uma conta de débito diferente da informada pelo ITP, basta que ele seja o titular da conta de débito no PSP Pagador. |
16 | PSP Pagador | Ação | Muda o estado do consentimento para AUTHORISED, conforme manifestado pelo Pagador. |
17 | PSP Pagador | Ação | Recolhe as confirmações ou rejeições de todos os aprovadores registrados para a conta |
18 | PSP Pagador | Comunicação | Redireciona o Pagador de volta ao ambiente do Iniciador |
19 | Iniciador | Comunicação | Recebe o Pagador de volta no seu aplicativo. |
20 | Iniciador | Ação | Valida os dados recebidos no redirecionamento |
21 | Iniciador | Ação | Loop para consulta do estado do consentimento até que o mesmo esteja em AUTHORISED |
22 | Iniciador | Comunicação | Notifica ao Pagador que o consentimento foi criado com sucesso e pode ser utilizado. |
23 | Pagador | Comunicação | Recebe notificação sobre o consentimento criado com sucesso e pode ser utilizado. |
...
3.2.1 - Fluxo para criação de um pagamento para Transferências Inteligentes
...
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 | Usuário contratante | 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 | ||
---|---|---|
| ||
|
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
...
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:
...
na |
...
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.
...
title | 13 - "Processa solicitação de transferência" |
---|
Nesta etapa, o PSP do pagador precisa validar as informações recebidas do iniciador e verificar se elas estão condizentes com as regras definidas na criação do consentimento de longa duração, alguns pontos a serem observados são:
...
transferência |
...
Se a data enviada para liquidação condiz com as configurações de período aceitas pelo usuário pagador no momento da autorização do consentimento;
...
Além de todos os erros síncronos e assíncronos que podem ocorrer durante as validações e listados na especificação da API.
...
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.
...