Descrição do Diagrama de Sequência
...
A Iniciadora deverá consultar periodicamente a Instituição Detentora de Conta para verificar o status da transação de iniciação pagamento. Os possíveis status de uma transação de iniciação de pagamento estão detalhados na documentação (Open Finance Brasil). Como sugestão, é indicado que a Instituição Iniciadora do pagamento implemente um retry exponencial e respeite o “rate limit” descriminado na documentação. A recomendação para uso do polling encontra-se detalhada na seção de “Recomendação uso de polling” (Open Finance Brasil).
GET pix/payments/{paymentId}
...
Caso a Iniciadora identifique que a transação de pagamento foi aprovada pela Detentora de Conta, poderá ser exibido o comprovante da efetivação da Transação de Pagamento. Caso o status do pagamento seja diferente de aprovado ou rejeitado, deverá ser apresentada a efetivação da solicitação de Iniciação de Pagamento, apresentando as informações segundo Guia de Usuário.
Os possíveis status de uma transação de iniciação de pagamento estão detalhados na documentação (Open Finance Brasil).
...
Existem validações assíncronas realizadas pelas instituições detentoras de contas que são feitas nas etapas do consentimento no fluxo da iniciação de pagamentos. O objetivo dessas validações é permitir que as iniciadoras de pagamentos comuniquem de forma assertiva os motivos de rejeição para o usuário
...
Momentos¹ | Etapa Diagrama | Etapa funil de consentimento | rejectionReason/code |
|---|---|---|---|
1 | Autenticação FAPI | Início da autenticação | FALHA_INFRAESTRUTURA TEMPO_EXPIRADO_AUTORIZACAO NAO_INFORMADO |
2 | Autentica Debtor | Conclusão da autenticação | FALHA_INFRAESTRUTURA TEMPO_EXPIRADO_AUTORIZACAO REJEITADO_USUARIO NAO_INFORMADO |
3 | Autoriza Iniciação de Pagamento | Autorização do cliente | FALHA_INFRAESTRUTURA CONTAS_ORIGEM_DESTINO_IGUAIS CONTA_NAO_PERMITE_PAGAMENTO SALDO_INSUFICIENTE VALOR_ACIMA_LIMITE QRCODE_INVALIDO VALOR_INVALIDO NAO_INFORMADO |
4 | access_token scope: (payments, openid) | Authorisation code emitido | FALHA_INFRAESTRUTURA TEMPO_EXPIRADO_CONSUMO NAO_INFORMADO |
...
...
O conteúdo criado nessa página deve ser utilizado pelas instituições que forem participar do desenvolvimento do piloto da jornada sem redirecionamento. Caso a instituição não tenha se voluntariado a participar seguir com a implementação da versão 3.0.0.
Descrição do Diagrama de Sequência
Detalhamento da iniciação de pagamento:
Debtor (Usuário) inicia o processo de pagamento na iniciadora.
Na iniciadora, o debtor seleciona a detentora e os dados de pagamentos: Observação: não serão ofertados, no primeiro momento, Pix Saque e Pix troco. Também não será possível agendamentos para Pix QR Codes Dinâmico com vencimento. Aqui referências a regulamentação relacionada ao Pix.
Estabelece TLS
Toda comunicação máquina-a-máquina (m2m) usará mTLS, conforme RFC 8705 e detalhado na especificação de segurança: Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3.
POST /tokens - Pedido de access_token e scope: payments, openid
Antes de começar o fluxo de iniciação de pagamento, a Instituição Iniciadora deverá ter se cadastrado como client na Instituição Detentora da Conta, em acordo com o especificado para o Registro Dinâmico de Clientes (Dynamic Client Registration). Os detalhes dessa etapa podem ser encontrados na especificação de segurança: Open Finance Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2. Uma vez cadastrada, a Instituição Iniciadora deverá obter o token de acesso (access_token) pelo fluxo de client credentials, conforme especificado pela RFC 6749, com os escopos payments e openid.
Valida certificado SSL e scopes
Ao receber a requisição da Iniciadora, o Servidor de Autorização da Instituição Detentora da Conta deverá validar o certificado SSL e os escopos, se esses estão de acordo com a especificação: payments e openid.
Gera access_token
Em caso de sucesso da validação, o Servidor de Autorização da Instituição Detentora da Conta deverá gerar o access_token, que será utilizado para a criação de consentimento.
Access_token (scope: payments, openid)
O Servidor de Autorização da Instituição Detentora da Conta deverá responder à requisição com o access_token conforme padrões definidos pelo GT de Segurança.
POST /payments/consents
Para a criação de consentimento, considerando o requerido para FAPI - Lodging Intent (Financial_API_Lodging_Intent.md), após a obtenção do token de acesso, a Instituição Iniciadora deverá usar esse token de acesso para fazer a requisição POST de consentimento. A criação do consentimento encontra-se detalhada na seção das APIs para Pagamentos (Open Finance Brasil).
201 Created
A API de Consentimento deverá responder o Http Status 201 e Payload contendo consentId, e status inicial do consentimento em AWAITING_AUTHORISATION conforme especificado na documentação Open Finance Brasil.
Redirecionamento
No caso do consentimento ter sido criado com sucesso, a Instituição Iniciadora deverá fazer o redirecionamento para a Instituição Detentora da Conta. Esse fluxo de redirecionamento deve considerar todos os requisitos definidos para o objeto de requisição OpenID Connect (Seção 4.3 da especificação de segurança - Third Party Provider End To End User Guide). Esse redirecionamento é o passo que permitirá o início da autenticação do usuário na Instituição Detentora da Conta.
Validações de negócios (Detentora)
Ao receber POST /payments/<version>/consents ou POST /payments/<version>/pix/payments é importante observar que a Detentora deverá validar as informações passadas pela Iniciadora nos campos do payload de envio do consentimento e do pagamento (como, por exemplo, valores e dados do creditado), além de caso veja necessidade, decodificar o payload para validar outras informações (atenção para a PACS008 e as regulamentações do Pix). A Detentora deve validar as informações de detalhes do payload com os dados de detalhes do consentimento, de acordo com a forma de pagamento. Caso os dados do detalhe informados no consentimento sejam diferente dos dados enviados na iniciação de pagamento, a Detentora deve retornar erro HTTP 422 Unprocessable Entity, com o code BENEFICIARIO_INCOMPATIVEL.
Efetivação do pagamento<<Async>>
A Detentora de Conta efetua a transação de pagamento entre o Debtor e Creditor através da forma de pagamento escolhida pelo Debtor. A efetivação da transação acontece de maneira assíncrona ao fluxo do Open Finance, seguindo as regras e interfaces do arranjo utilizado (apenas PIX disponível nesse momento).
Loop (Polling)
A Iniciadora deverá consultar periodicamente a Instituição Detentora de Conta para verificar o status da transação de iniciação pagamento. Os possíveis status de uma transação de iniciação de pagamento estão detalhados na documentação (Open Finance Brasil). Como sugestão, é indicado que a Instituição Iniciadora do pagamento implemente um retry exponencial e respeite o “rate limit” descriminado na documentação. A recomendação para uso do polling encontra-se detalhada na seção de “Recomendação uso de polling” (Open Finance Brasil).
GET pix/payments/{paymentId}
Durante o período de polling a Iniciadora deverá consultar o status da transação através da rota “Get pix/payments/{paymentId}” informado o respectivo paymentId da transação. A consulta encontra-se detalhada na seção das APIs para Pagamentos (Open Finance Brasil).
Exibe comprovante de iniciação de pagamento
Caso a Iniciadora identifique que a transação de pagamento foi aprovada pela Detentora de Conta, poderá ser exibido o comprovante da efetivação da Transação de Pagamento. Caso o status do pagamento seja diferente de aprovado ou rejeitado, deverá ser apresentada a efetivação da solicitação de Iniciação de Pagamento, apresentando as informações segundo Guia de Usuário.
Os possíveis status de uma transação de iniciação de pagamento estão detalhados na documentação (Open Finance Brasil).
Momentos de validações assíncronas na etapa do consentimento
Existem validações assíncronas realizadas pelas instituições detentoras de contas que são feitas nas etapas do consentimento no fluxo da iniciação de pagamentos. O objetivo dessas validações é permitir que as iniciadoras de pagamentos comuniquem de forma assertiva os motivos de rejeição para o usuário
...
Momentos¹
...
Etapa Diagrama
...
Etapa funil de consentimento
...
rejectionReason/code
...
1
...
Autenticação FAPI
...
Início da autenticação
...
FALHA_INFRAESTRUTURA
TEMPO_EXPIRADO_AUTORIZACAO
NAO_INFORMADO
...
2
...
Autentica Debtor
...
Conclusão da autenticação
...
FALHA_INFRAESTRUTURA
TEMPO_EXPIRADO_AUTORIZACAO
REJEITADO_USUARIO
NAO_INFORMADO
...
3
...
Autoriza Iniciação de Pagamento
...
Autorização do cliente
...
FALHA_INFRAESTRUTURA
CONTAS_ORIGEM_DESTINO_IGUAIS
CONTA_NAO_PERMITE_PAGAMENTO
SALDO_INSUFICIENTE
VALOR_ACIMA_LIMITE
QRCODE_INVALIDO
VALOR_INVALIDO
NAO_INFORMADO
...
4
...
access_token scope: (payments, openid)
...
Authorisation code emitido
FALHA_INFRAESTRUTURA
TEMPO_EXPIRADO_CONSUMO
...