Confira abaixo o fluxograma completo do ciclo de vida de uma jornada de consentimento para iniciação de pagamento.
...
Para utilizar o recurso de pagamento, temos 2 fluxos distintos:
As APIs de pagamento ITP : inteiramente por meio de APIs RESTful, recomendadas para desenvolvedores que desejam implementar toda a jornada em suas próprias telas, incluindo as fases de criação de consentimento, aprovação/rejeição de consentimento e redirecionamento. Para mais detalhes, veja a documentação APIs de Pagamento ITP .
O Whitelabel de Pagamento ITP : Com apenas 3 chamadas de API para iniciar e finalizar o processo, utilizando as telas de whitelabel para a criação de consentimento, aprovação/rejeição de consentimento e fluxos de redirecionamento. Para mais detalhes, veja a documentação White label ITP
...
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
A ordem dos eventos segue o fluxo da máquina de estados acima, porém, devido ao tempo de processamento/transição de cada evento ser muito rápido e devido a questões relacionadas à velocidade e latência nos tempos de resposta das chamadas RESTful, pode ser que o o evento consent:consumed chega antes do evento consent:finish no endpoint do webhook. Porém, aconselhamos seguir a ordem descrita e verificar o carimbo de data/hora de geração do evento. |
Evento | Descrição |
|---|---|
before:consent:create | Recebemos uma solicitação para criação de consentimento. |
after:consent:create | Todos os campos de consentimento foram validados, estão seguindo todos os padrões necessários e foi criado. |
consent:approved | O consentimento foi aprovado pelo usuário. |
consent:rejected | O consentimento foi rejeitado pelo usuário. |
consent:consumed | O consentimento foi consumido pela Instituição Financeira. |
consent:polling | Sondagem para verificar a situação do pagamento na Instituição Financeira. |
consent:finish | O dinheiro foi transferido com sucesso ou houve algum erro reportado por uma das Instituições Financeiras envolvidas na transação. Mais informações são fornecidas nos dados do campo . |
consent:expired | O consentimento expirou. Não foi aprovado ou rejeitado após 5 minutos da criação OU após aprovação/rejeição não foi consumido em 70 minutos. |
consent:revoke | Consentimento revogado pelo usuário (geralmente após aprovação) |
Detalhes do status
Alguns dos status seguem os padrões oficiais brasileiros, e alguns deles são específicos para nossa implementação. Algumas definições são importantes para lidar com a transição de estados de consentimento em diferentes momentos do fluxo. Para obter mais detalhes sobre os eventos padrão, veja abaixo:
AWAITING_AUTHORISATION
O consentimento é sempre criado com o status AWAITING_AUTHORISATION. Ele pode ser aprovado somente antes do tempo de expiração de 5 minutos, assumindo o status AUTHORISED. Se não, deve assumir o status REJECTED caso expire ou seja cancelado pelo usuário.
Lembrando que o usuário pode cancelar o consentimento no lado da detentora de conta e por sua vez ela deve mudar o status do consentimento para REJECTED.
AUTHORISED
Para o cenário em que o status assumiu AUTHORISED, o tempo máximo do expirationDateTime do consentimento deve assumir "now + 60 minutos". Este é o tempo para consumir o consentimento autorizado, mudando seu status para CONSUMED. Não é possível prorrogar este tempo e a criação de um novo consentimento será necessária para os cenários de insucesso.
O tempo do expirationDateTime é garantido com os 15 minutos do access token, sendo possível utilizar mais três refresh tokens até totalizar 60 minutos.
REJECTED
Em caso de consentimento expirado a Detentora deverá retornar o status REJECTED.
Em caso de consentimento rejeitado pelo usuário ou por regra de negócio da Detentora, o status deverá ser retornado como REJECTED.
CONSUMED
O consentimento assume o status CONSUMED após ocorrer o processamento da iniciação do pagamento, seja ele com sucesso (HTTP 201) ou ainda em casos de insucesso (HTTP 422) retornados pela Detentora. Para os demais códigos HTTP não há mudança de status do consentimento, o mesmo permanecerá AUTHORISED, respeitando o tempo máximo de expiração do consentimento (60 minutos).
Recomendação uso de polling
A consulta via GET, para verificar o processamento da transação, pode ser efetuada a qualquer momento desde que se respeite o rate limit definido.
Situação de Pagamento PIX
A máquina de estado oficial do PIX pode ser encontrada em Máquina de estado Open Finance Brasil - v3.0.0-beta.2 - Pagamento .
Abaixo está uma descrição dos status relacionados à máquina de estado relevantes para as modalidades de pagamento Pix:
RCVD (recebido)
O estado indica que o pedido de pagamento foi recebido com sucesso pelo titular, mas ainda existem validações a efetuar antes de o mesmo ser submetido para liquidação.
PATC (correto técnico parcialmente aceito)
O status indica que a transação precisa da confirmação de mais autorizadores antes que o processamento do pagamento possa prosseguir.
CANC (cancelado)
O status indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes de ser confirmada (ACCP) ou rejeitada (RJCT) pelo titular.
ACCP (perfil de cliente aceito)
O status indica que todas as verificações necessárias já foram realizadas pelo titular e que a transação está pronta para ser enviada para liquidação (no SPI se for um Pix para outra instituição ou internamente se for para outra conta na mesma instituição ).
ACPD (compensação aceita processada)
O status indica que o titular já submeteu a transação para liquidação, mas ainda não tem confirmação se ela foi liquidada ou rejeitada.
RJCT (rejeitado)
O status indica que a transação foi rejeitada pelo titular ou pelo SPI.
ACSC (conta de devedor concluída com liquidação aceita)
O status indica que a transação foi realizada pelo titular ou pelo SPI.
PDNG (Pendente)
O status indica que o titular reteve temporariamente a transação Pix para análise.
SCHD (Programado)
O status indica que a transação Pix foi agendada com sucesso no titular.
Abaixo estão listados os códigos da razão pela qual o pagamento foi rejeitado
SALDO_INSUFICIENTE - Saldo do usuário: Valida se a conta selecionada possui saldo suficiente para realizar o pagamento.
VALOR_ACIMA_LIMITE - Limites da transação: Valida se valor (ou quantidade de transações) ultrapassa faixa de limite parametrizada na detentora.
VALOR_INVALIDO - Valor informado (QR Code): Valida se valor enviado é válido para o QR Code informado.
COBRANCA_INVALIDA - Cobrança inválida: Valida expiração, vencimento e status.
NAO_INFORMADO - Demais validações não explicitamente informadas (ex. suspeita de fraude).
PAGAMENTO_DIVERGENTE_CONSENTIMENTO - Divergência entre pagamento e consentimento: Valida se dados do pagamento são diferentes dos dados do consentimento.
DETALHE_PAGAMENTO_INVALIDO - Detalhes do pagamento: Valida se determinado parâmetro informado obedece às regras de negócio.
PAGAMENTO_RECUSADO_DETENTORA - Recusado pela detentora: Valida se pagamento foi recusado pela detentora, com a descrição do motivo de recusa (ex. chave Pix inválida, QRCode inválido, conta bloqueada);
PAGAMENTO_RECUSADO_SPI - Validação SPI: Externaliza validações no SPI.
FALHA_INFRAESTRUTURA
Casos de erro para validações assíncronas no DICT
Neste cenário o pagamento é criado com sucesso (status RCVD) e o consentimento é consumido (status CONSUMED), porém, as validações contra o DICT só ocorrerão de forma assíncrona e em caso de negativa será percebido pela iniciadora na consulta do pagamento (GET /Payments).
Retorno esperado do endpoint GET /Payments: HTTP Code 200 - OK.
Status do Pagamento: RJCT (Rejected)
Trilhas para implementação do Pix Open Finance
Integre com White Label de Pagamentos
...
...