Payment Order Flow
  • 24 Nov 2022
  • 5 Minutes To Read
  • Dark
    Light
  • PDF

Payment Order Flow

  • Dark
    Light
  • PDF

The processing of a payment order is done in four stages: initiate, accept, clear, and settle. After a payment passes each of these stages, it receives a specific status. If at any of these stages, the payment is rejected, it will receive a rejected RJCT status.

The payment statuses are:

  • Received (RCVD): Payment initiation has been received (input has been validated).
  • Accepted technical validation (ACTC): Payment order has been accepted based on the requested execution time.
  • Accepted settlement in process (ACSP): Payment order has been executed (the corresponding transaction, either debit or credit, has been posted in Mambu core).
  • Accepted settlement completed (ACSC): Payment order completed (SEPA message has been sent to callout URL).
  • Rejected (RJCT): Payment request has been rejected.

You may also set up webhook or streaming API notifications in order to receive notifications when a payment order goes through each of these stages and gets a different payment status. For more information, see Payment events.

Payment order stages and statuses

Below we go into more detail about each of the payment order stages and statuses.

Payment order flow with stages and states

Initiate stage

The payment order is initiated by the Payment Service User via the Payments API. In this stage, there are several validations done on the SEPA debtor agent, SEPA creditor agent, and the currency.

If the payment order does not pass all of these validations, it can get a rejected (RJCT) status.

If the payment order does pass all of these validations, then it will get a received (RCVD) status.

Accept stage

The payment order is validated and enriched with additional data, such as a BIC code.

If the execution date is the current date in the case of credit transfers, then the payment order gets an accepted technical validation (ACTC) status.

Otherwise, it will get a rejected (RJCT) status.

Clear stage

In the clear stage, certain checks are carried out and if the payment order passes all the checks then the actual transaction on the deposit account is carried out and the payment gets an accepted settlement in process (ACSP) status. Next, it will move to the settlement stage.

If the payment order does not pass all the checks, then the payment order gets a rejected (RJCT) status. This may happen for example, if:

  • The debtor has insufficient funds.
  • The account is blocked.
  • The account does not exist.
  • The IBAN is not linked to a deposit account in Mambu.
Please Note
The routing can be determined in consideration of the following criteria: account number or IBAN of the creditor or debtor, bank account number or BIC of the creditor or debtor.

Settle stage

In the settlement stage, we initiate the SEPA transaction (either pacs 008 or pacs 003) to the callout URL.

If everything goes well, the payment order is executed on the beneficiary side. In this case, the payment order will get an accepted settlement completed (ACSC) status.

For more information, see Settlement.

If there is an issue at this point, for example, the URL is not accessible, then the payment gets a rejected (RJCT) status.

Rejected

If the payment is rejected in any stage of the payment order flow, it gets a rejected (RJCT) status.

Please Note

A payment will also receive a rejected (RJCT) status if:

  • an incoming pacs.002 or pacs.004 message is received
  • an incoming camt.056 is authorized via pacs.004

Settlement

In Mambu we deal with two different settlement flows, intrabank and interbank.

Intrabank payment flow

Intrabank payments occur when the originator and the beneficiary are in the same financial institution. In this case, a transfer transaction is made from the originator to the account of the beneficiary. The paymentDetails object of the transfer will include details of the payment request, including the end to end ID and scheme used, for example SEPA.

In this case, the flow ends when the settlement is complete and the beneficiary account is credited or debited. The payment message doesn't reach the Mambu Payment Gateway UI because the Mambu Payment Gateway only hands interbank payments.

Interbank payment flow

Interbank payments occur when the originator and beneficiary are in different financial institutions.

In this case, the Mambu Payment Gateway generates the files necessary for the specific payment based on the scheme being used. For example, in an outgoing SEPA payment, after Mambu receives the payment request and identifies that it is a SEPA credit transfer payment, Mambu will generate a pacs.008 message. For more information about pacs.008 messages, see Pacs.008.

The Mambu Payment Gateway will create a deposit or withdrawal transaction against the customer account matching the IBAN contained in the payment message. The paymentsDetails object will contain information about the original request, including the payment scheme used and end to end ID.

This flow ends once the payment message is sent to the automated clearing house (ACH) or the clearing and settlement mechanism (CSM) to proceed with the settle procedure.

Payment events

You can opt to receive webhook or streaming API notifications as a payment goes through each of the stages and statuses in the payment order flow.

For more information on setting up Streaming API events, see Streaming API in our User Guide and the Streaming API Reference.

For more information about setting up webhook notifications, see Defining a New Webhook.

In order to create such events, when creating your notification template, you must select Payment Order as the event target and Payment Order Activity as the event trigger.

Please Note

The Payment Order Activity event trigger relates only to credit transfer events.

If you want to receive notifications about direct debits, you may select the Collection Order Activity event trigger.

Please Note

You will only have access to the payment-related event targets and event triggers if you have the Payments capability enabled.

Placeholders

To define the content of your notification, you have access to payment-related placeholders. For more information about placeholders, see Placeholders.

Below is a list of the placeholders available for payments:

Creditor

  • Creditor Account Currency
  • Creditor Account IBAN
  • Creditor Account Id
  • Creditor Account Identification
  • Creditor Account Scheme
  • Creditor Address - Building Number
  • Creditor Address - City
  • Creditor Address - Country Code
  • Creditor Address - Line1
  • Creditor Address - Line2
  • Creditor Address - Postal Code
  • Creditor Address - Street
  • Creditor BICFI
  • Creditor Name

Debtor

  • Debtor Account Currency
  • Debtor Account IBAN
  • Debtor Account Id
  • Debtor Account Identification
  • Debtor Account Scheme
  • Debtor Address - Building Number
  • Debtor Address - City
  • Debtor Address - Country Code
  • Debtor Address - Line1
  • Debtor Address - Line2
  • Debtor Address - Postal Code
  • Debtor Address - Street
  • Debtor BICFI
  • Debtor Name

Payment

  • End To End Identification
  • Error Description
  • Errors
  • Instructed Amount
  • Instructed Amount Currency
  • Instructed Transaction ID
  • Instruction Identification
  • Message Identification
  • Purpose Code
  • Remittance Issuer
  • Remittance Reference
  • Remittance Reference Type
  • Remittance Unstructured
  • Requested Execution Date
  • Requested Execution Time
  • Settlement Date
  • Status
  • Transaction ID
  • Ultimate Creditor
  • Ultimate Debtor
  • Value Date

Was this article helpful?