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:

  1. The payment is being created (CREA and ACTC)
  2. The payment has been initiated (PDNG)
  3. The payment has been successfully (ACSC)
  4. The payment has failed (RJCT)

Payment transaction satus during the payment flow

1. Payment is being created

CREA temporary statusPayment has been created on Bridge side
ACTC temporary statusPayment 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.

PDNG temporary statusThis 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

ACSC final statusPayment 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.

RJCT final statusPayment 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 reasonDescription
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
nullIn some cases, 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

What’s Next