In the table below, it is possible to observe which are the possible returns of the rejectionReason field, inside the consent flow, that can be sent in each step involved with the consent, for the payment flow:
Consent funnel steps | Code |
|---|---|
start of authentication | FALHA_INFRAESTRUTURA, TEMPO_EXPIRADO_AUTORIZAÇAO |
authentication completion | FALHA_INFRAESTRUTURA, TEMPO_EXPIRADO_AUTORIZAÇAO, REJEITADO_USUARIO |
Customer Authorization | FALHA_INFRAESTRUTURA, CONTAS_ORIGEM_DESTINO_IGUAIS, CONTA_SALARIO, SALDO_INSUFICIENTE, VALOR_ACIMA_LIMITE, QRCODE_INVALIDO |
Authorization code issued | FALHA_INFRAESTRUTURA, TEMPO_EXPIRADO_CONSUMO |
And below are the possible returns for the same rejectionReason field, but for the business rejection of the payment flow.
...
| Code Block |
|---|
"rejectionReason": {
"code": "NAO_INFORMADO",
"detail": "Não Informado"
} |
Journey expired due to timeout or canceled by the user
As of this product update, you have the whitelabel journey expiration scenario, in which a user who has canceled the flow, before being redirected to the transaction confirmation institution, or exceeds the token generation timeout, tries return to the same journey that was generated (same JourneyID). An error screen is presented, as shown in the example below, and the user is redirected to the same endpoint registered in the Redirect URL field in your application.
...
Example of return on journey cancellation event, in the webhook
| Code Block |
|---|
{
"event": "journey:cancel",
"eventDate": "2023-11-22T18:55:54.335Z",
"data": {
"journeyId": "FlxcMSUD4q_tTiCipuCOrSwfBKhbUP0_"
}
} |
Example of return on journey expiration event, in the webhook
| Code Block |
|---|
{
"event": "journey:expired",
"eventDate": "2023-11-22T18:55:54.335Z",
"data": {
"journeyId": "FlxcMSUD4q_tTiCipuCOrSwfBKhbUP0_"
}
} |