Payments statuses
Once your users start a payment process, the payment request and the payment transactions will have a status. For single payments, 1 payment request = 1 transaction and their status are always identical.
Our statuses follow a simplified version of the ISO 20022 standard used by STET system.
We can separate the statuses in 3 categories:
- The payment is being created
- The payment is initiated with success
- The payment is rejected
1. Payment is being created
| Status | Description |
|---|---|
CREA temporary status | Payment has being created on Bridge side (after POST /payment-requests) |
ACTC temporary status | Payment has been created on bank side |
2. Payment is initiated with success
| Status | Description |
|---|---|
PDNG temporary status | Payment has been confirmed and must now be executed by the bank (the bank should do it within 1 open day except for scheduled payments) |
PART final status (bulk payments only) | In this case, please check the transactions statuses because it means some of them might be successful and some might be rejected Payment has been confirmed and must now be executed by the bank (the bank should do it within 1 open day). |
ACSC final status | Payment has been executed by the bank (request succeeded) |
Once the payer confirmed a payment in 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 checking the payment request or transaction status, it should have one of these statuses:
ACSC(meaning the payment is already executed, usually instant payment)PDNG(see explanation below*)
*When at this step, the payments cannot be canceled anymore (except for scheduled payment) and the bank will execute it asap. It will take approx. 1 open day to see the payments changing their status from PDNG to ACSC.
Important: the payer can close our hosted page without your callback urls being called
When integrating our solution, please keep in mind that your users can close the tab displaying our hosted page anytime and consequently might not be redirected to your callback URL.
To keep your data in sync, we recommend you to integrate our Webhooks events to be updated on payment request statuses.
LCL status flow stops at "PDNG"
LCL doesn't use
ACSCstatus. We recommend you to consider your payment as a success once you see a LCL payment with the statusPDNGafter 3 open days
3. Payment is rejected
| Status | Description |
|---|---|
RJCT final status | Payment has been rejected |
You implemented this feature before 30th of March 2022?
Then you might find payments with other statuses than the ones described here. You can see the full list on this page
If the payment status is RJCT then it can have status_reason giving you more information about why the payment 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 Example: Caisse d'Epargne rejects payments inferior to 1€ with this status reason. |
| 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 about 2 years ago