Payment requests and transactions 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 4 categories:
- The payment is being created (CREA and ACTC)
- The payment is initiated (PDNG)
- The payment is executed (ACSC)
- The payment is rejected (RJCT)
Payment transaction satus during the payment flow
1. Payment is being created
| Status | Description |
|---|---|
CREA temporary status | Payment has been created on Bridge side |
ACTC temporary status | Payment has been created on bank side |
2. Payment is initiated
If your customer successfully confirm the payment on his bank interface, the payment request and the related payment transaction will be initiated and they should have the PDNG status. Concerning instant payments, they are directly executed (see next section).
| 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) |
As soon as a payment request has a PDNG status, the related payment link will have the COMPLETE final status.
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 Payments webhooks to be updated on payment request statuses.
3. Payment is executed
| Status | Description |
|---|---|
ACSC final status | Payment has been executed by the bank |
Banks with no execution status
Some rare banks like LCL don't know the execution status. So the status flow stops at "PDNG" and the bank doesn't use the
ACSCstatus. If it's incompatible with your business, you can exclude these banks from the Pay by Link in the customization module.
4. Payment is rejected
A payment can be rejected at several stages and for different reasons:
- when we create the payment
- when your customer tries to pay on his bank interface (example: drop)
- when the bank initiates the payment (example: blocked account)
- when the bank executes the payment (example : bank fraud detection)
| Status | Description |
|---|---|
RJCT final status | Payment has been rejected |
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 5 months ago