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:

  1. The payment is being created (CREA and ACTC)
  2. The payment is initiated (PDNG)
  3. The payment is executed (ACSC)
  4. The payment is rejected (RJCT)
7299

Payment transaction satus during the payment flow

1. Payment is being created

StatusDescription
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).

StatusDescription
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)

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

StatusDescription
ACSC final statusPayment 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 ACSC status. 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)
StatusDescription
RJCT final statusPayment 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 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

What’s Next