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