Payments Statuses
Once your users start a payment process, the payment request will have a status. The statuses used follow the ISO 20022 standard.
We can separate the statuses in 3 categories:
- The payment initiation is being created or processed
- The payment initiation is a success
- The payment initiation is rejected or cancelled
1. Payment initiation is being created or processed
| Status | Description |
|---|---|
ACTC temporary status | Payment request is registered (after POST /payment-requests) |
ACCP temporary status | Payment request is being processed (not used by every bank) |
2. Payment initiation is a success
| Status | Description |
|---|---|
PDNG temporary status | Payment request has been confirmed and must now be executed by the bank (the bank should do it within 1 open day) |
ACSP temporary status | Payment request has been confirmed and must now be executed by the bank (the bank should do it within 1 open day) |
ACSC final status | Payment request accepted by the bank (request succeeded) |
Once your users confirmed a payment from their bank interface, if everything went well, they will be redirect to the success callback url you set up in the v2/payment-requests call.
At this step when you will check the payment request status (not the transaction status), it should have one of these 3 statuses:
ACSC(meaning the payment is already processed, usually instant payment)PDNG(see explanation below*)ACSP(see explanation below*)
*When we are at this step, the payments cannot be revoked and the bank has the obligation to confirm them. It's only a matter of time to see the payments changing their status from PDNG or ACSP to ACSC and it usually takes 1 open day.
If the payment status is not
ACSC,PDNGorACSPIf the user is redirected to the success callback url and the payment status is not
ACSC,PDNGorACSP, it means the payment request failed
Important: your users can quit before accessing your callback URL
When integrating our solution, please keep in mind that your users can quit at any step and then they might not be redirected to your callback URL (then you won't be able to get their payment status at this step). We recommend you to develop a job to check payments status regularly thanks to the endpoint List payment requests. This endpoint will list every payment request with a final status (
ACSC,RJCT,CANC)
3. Payment initiation is rejected or cancelled
| Status | Description |
|---|---|
CANC final status | Payment request is cancelled |
RJCT final status | Payment request is rejected |
If the payment request status is RJCT then it can have status_reason giving you more information about why the payment request has been rejected.
Here is the list of every possible status reason you can get:
| Status reason | Description |
|---|---|
| AC01 | (IncorrectAccountNumber): the account number is either invalid or does not exist) |
| AC04 | (ClosedAccountNumber): the account is closed and cannot be used |
| AC06 | (BlockedAccount): the account is blocked and cannot be used) |
| AG01 | (Transaction forbidden): Transaction forbidden on this type of account |
| AM18 | (InvalidNumberOfTransactions): the number of transactions exceeds the ASPSP acceptance limit |
| CH03 | (RequestedExecutionDateOrRequestedCollectionDateTooFarInFuture): The requested execution date is too far in the future |
| CUST | (RequestedByCustomer): The reject is due to the debtor: refusal or lack of liquidity |
| DS02 | (OrderCancelled): An authorized user has cancelled the order |
| FF01 | (InvalidFileFormat): The reject is due to the original Payment Request which is invalid (syntax, structure or values) |
| FRAD | (FraudulentOriginated): the Payment Request is considered as fraudulent |
| MS03 | (NotSpecifiedReasonAgentGenerated): No reason specified by the ASPSP (usually the bank) |
| NOAS | (NoAnswerFromCustomer): The PSU (the user) has neither accepted nor rejected the Payment Request and a timeout has occurred |
| RR01 | (MissingDebtorAccountOrIdentification): The Debtor account and/or Identification are missing or inconsistent |
| RR03 | (MissingCreditorNameOrAddress): Specification of the creditor’s name and/or address needed for regulatory requirements is insufficient or missing |
| RR04 | (RegulatoryReason): Reject from regulatory reason |
| RR12 | (InvalidPartyID): Invalid or missing identification required within a particular country or payment type |
| null | For a few international banks like Revolut, a payment can have a RJCT status without having a status_reason detailed. In this case, the field won't be displayed in the API response when you call the "Get payment request" endpoint |
Updated almost 3 years ago