Payment Order Flow

Payment order flows describe the stages that a payment order may go through and the payment status it may have after each stage. Mambu supports one payment order flow for outgoing payments and two payment order flows for incoming payments. For a list of the available payment statuses, see Payment statuses.

With regards to incoming payments, in one payment order process, AML checks happen before the payment order is created. This is the current default process for all customers. In the other payment order process, AML checks happen after the payment order is created. If you want to enable this second payment order flow process, please contact us through Mambu Support.

The main difference between the two incoming payment order flow processes is that when AML checks happen before the payment order is created, you and your other payment systems are not notified of rejected incoming payments.

However, when AML checks happen after payment order creation, you and your other payment systems will be notified about rejected incoming payments and you're able to manage the rejected incoming payments.

Below we describe all of the available flows and you may visit the relevant section:

• Outgoing payment order flow
• Incoming payment order flow with AML checks before payment order creation (default)
• Incoming payment order flow with AML checks after payment order creation (available upon request)

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

Payment statuses

The table below lists the available payment statuses that a payment order can be in.

Outgoing payment order flow

The processing of a payment order is done in four stages: initiate, accept, clear, and settle. AML checks happen during the settle stage. 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.

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.

Settle stage

In the settlement stage, outgoing payments go through AML checks.

If everything goes well, we initiate the SEPA transaction (either pacs 008 or pacs 003) to the callout URL. 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, or the outgoing payment doesn't pass AML checks, 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.

Incoming payment order flow with AML checks before payment order creation

This is the default payment order flow process for incoming payments. A payment order is created only if the incoming payment passes AML checks and thereafter the processing of the 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.

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.

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.

Incoming payment order flow with AML checks after payment order creation

The processing of a payment order is done in five stages: initiate, accept, clear, AML check, 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. This payment order flow process allows you to properly manage rejected incoming payment order flows.

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 payment gets a customer profile validation in progress (CPVP) status.

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.

AML check stage

In the AML check 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.

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.

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 handles 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.

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