Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Nesta ramificação, você encontrará informações sobre o comportamento dos consentimentos, dirigido por eventos. Eventos como tempo, sinais ou operações podem fazer com que o estado de um objeto seja alterado.

Os possíveis status do consentimento são

  • AWAITING_AUTHORISATION - Aguardando autorização

  • AUTHORISED - Autorizado

  • REJECTED - Rejeitado

  • CONSUMED - Consumido

Algumas definições são importantes para tratar a transição dos estados do consentimento em diferentes momentos do fluxo:

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.

Os possíveis status do pagamento Pix, são

  • RCVD

  • PATC

  • CANC

  • ACCP

  • ACPD

  • RJCT

  • ACSC

  • PDNG

  • SCHD

Status relacionados a máquina de estados pertinente aos tipos de pagamento Pix

RCVD (Received)

  • O status indica que a requisição de pagamento foi recebida com sucesso pela detentora, mas ainda há validações a serem feitas antes de ser submetida para liquidação.

PATC (Partially Accepted Technical Correct)

  • O status indica que a transação precisa da confirmação de mais autorizadores para que o processamento do pagamento possa prosseguir.

CANC (Cancelled)

  • O status indica que a transação Pix pendente foi cancelada com sucesso pelo usuário antes que fosse confirmada (ACCP) ou rejeitada (RJCT) pela detentora.

ACCP( Accepted Customer Profile)

  • O status indica que todas as verificações necessárias já foram realizadas pela detentora e que a transação está pronta para ser enviada para liquidação (no SPI se for Pix para outra instituição ou internamente se for para outra conta na mesma instituição).

ACPD (Accepted Clearing Processed)

  • O status indica que a detentora já submeteu a transação para liquidação, mas ainda não tem a confirmação se foi liquidada ou rejeitada.

RJCT (Rejected)

  • O status indica que a transação foi rejeitada pela detentora ou pelo SPI.

ACSC (Accepted Settlement Completed Debtor Account)

  • O status indica que a transação foi efetivada pela detentora ou pelo SPI.

PDNG (Pending)

  • O status indica que a detentora reteve temporariamente a transação Pix para análise.

SCHD (Scheduled)

  • O status indica que a transação Pix foi agendada com sucesso na detentora.

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)

  • No labels