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

Version 1 Next »

In this branch, you will find information about the behavior of consents, driven by events. Events such as weather, signals, or operations can cause an object's state to change.

 

Possible consent statuses are

  • AWAITING_AUTHORISATION - Awaiting authorization

  • AUTHORIZED - Authorized

  • REJECTED - Rejected

  • CONSUMED - Consumed

 

 

 

Some definitions are important to handle the transition of consent states at different times of the flow:

AWAITING_AUTHORISATION

  • Consent is always created with the status AWAITING_AUTHORISATION. It can be approved only before the 5 minute expiration time, assuming the AUTHORISED status. If not, it must assume the REJECTED status if it expires or is canceled by the user.

Remembering that the user can cancel the consent on the account holder's side and in turn she must change the consent status to REJECTED.

AUTHORISED

  • For the scenario where the status assumed AUTHORISED, the maximum time of the expirationDateTime of the consent must assume "now + 60 minutes". This is the time to consume the authorized consent, changing its status to CONSUMED. It is not possible to extend this time and the creation of a new consent will be necessary for failure scenarios.

The expirationDateTime time is guaranteed with the 15 minutes of the access token, and it is possible to use three more refresh tokens up to a total of 60 minutes.

REJECTED

  • In case of expired consent, the Holder must return the REJECTED status.

  • In case of consent rejected by the user or by the Holder's business rule, the status must be returned as REJECTED.

CONSUMED

  • The consent assumes CONSUMED status after processing the initiation of the payment, whether it is successful (HTTP 201) or even in cases of failure (HTTP 422) returned by the Holder. For the other HTTP codes, there is no change in the consent status, it will remain AUTHORISED, respecting the maximum consent expiration time (60 minutes).

Recommendation to use polling

The query via GET, to verify the processing of the transaction, can be carried out at any time as long as the defined rate limit is respected.

 

Possible Pix payment statuses are

  • RCVD

  • PATC

  • DEL

  • ACCP

  • ACPD

  • RJCT

  • ACSC

  • PDNG

  • SCHD

 

 

Below is a description of the statuses related to the state machine relevant to the Pix payment types.

RCVD (Received)

  • The status indicates that the payment request was successfully received by the holder, but there are still validations to be made before it is submitted for settlement.

PATC (Partially Accepted Technical Correct)

  • The status indicates that the transaction needs confirmation from more authorizers before payment processing can proceed.

CANC (Cancelled)

  • The status indicates that the pending Pix transaction was successfully canceled by the user before it was confirmed (ACCP) or rejected (RJCT) by the holder.

ACCP( Accepted Customer Profile)

  • The status indicates that all necessary checks have already been carried out by the holder and that the transaction is ready to be sent for settlement (in the SPI if it is a Pix for another institution or internally if it is for another account at the same institution).

ACPD (Accepted Clearing Processed)

  • The status indicates that the holder has already submitted the transaction for settlement, but still does not have confirmation whether it was settled or rejected.

RJCT (Rejected)

  • The status indicates that the transaction was rejected by the holder or the SPI.

ACSC (Accepted Settlement Completed Debtor Account)

  • The status indicates that the transaction was carried out by the holder or by the SPI.

PDNG (Pending)

  • The status indicates that the holder has temporarily held the Pix transaction for review.

SCHD (Scheduled)

  • The status indicates that the Pix transaction was successfully scheduled at the holder.

  • No labels