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:

  1. The payment is being created
  2. The payment is initiated with success
  3. The payment is rejected

1. Payment is being created

CREA temporary statusPayment has being created on Bridge side (after POST /payment-requests)
ACTC temporary statusPayment has been created on bank side

2. Payment is initiated with success

PDNG temporary statusPayment 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 statusPayment 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 ACSC status. We recommend you to consider your payment as a success once you see a LCL payment with the status PDNG after 3 open days

3. Payment is rejected

RJCT final statusPayment 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 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
nullFor 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