Payment requests and transactions statuses
When your users initiate a payment process, both the payment request and the corresponding payment transaction will have specific statuses. In the case of single payments, where 1 payment request corresponds to 1 transaction, the statuses of both components will always be identical.
Our payment statuses are designed to align with a simplified version of the ISO 20022 standard, which is also used by STET system.
We categorize these statuses into four distinct categories:
- The payment is being created (CREA and ACTC)
- The payment has been initiated (PDNG)
- The payment has been successfully (ACSC)
- The payment has been (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).
When your customer successfully confirms the payment on their bank interface, both the payment request and the associated payment transaction will be initiated, marked with the PDNG status.
| Status | Description |
|---|---|
PDNG temporary status | This status signifies that the payment has been confirmed and is awaiting execution by the bank. The bank is responsible for executing the payment promptly, typically within one open day, unless the payment is scheduled for a later date. |
As soon as a payment request achieves the PDNG status, the associated payment link will transition to the COMPLETE final status.
The payer can close the payment page without your callback urls being called
When integrating our solution, it's important to consider that users can close the tab displaying our hosted page at any time. This might prevent them from being redirected to your callback URL.
To maintain data synchronization and stay informed about payment request statuses, we strongly recommend integrating our Payments webhooks. This ensures you receive real-time updates on payment request statuses, even if users close the hosted page abruptly.
3. Payment is executed
When a payment has been successfully executed by the bank, it will be marked with the ACSC status. This status is considered a final status, indicating that the payment has been successfully completed
| Status | Description |
|---|---|
ACSC final status | Payment has been executed by the bank |
Exception: Banks with No Execution Status
It's important to note that some banks, such as LCL, do not provide an execution status. For these banks, the status flow stops at "PDNG," and the ACSC status is not used. If this is incompatible with your business requirements, you can choose to exclude these banks from the Pay by Link feature within the customization module.
4. Payment is rejected
Payments can be rejected at various stages and for different reasons, including:
- During payment creation.
- When your customer attempts to make payment on their bank interface (e.g., due to a drop in the process).
- When the bank initiates the payment (e.g., due to a blocked account).
- When the bank executes the payment (e.g., due to bank fraud detection).
When a payment is rejected, it will be marked with the RJCT status, which is also a final status.
| Status | Description |
|---|---|
RJCT final status | Payment has been rejected |
If the payment status is RJCT, additional information can be obtained through the status_reason, providing insights into why the payment was rejected.
Here is a list of possible status reasons that can help you understand why a payment has been rejected:
| 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 3 months ago