Bacs Inbound Payments

Inbound Direct Credit payment

This template allows you to initiate Inbound Direct Credit transactions for existing Mambu clients that have Mambu deposit accounts via the Bacs Payment Schemes Limited (Bacs).

The process is automatically triggered when a payment is initiated from the Bacs system and the TransactionSettled webhook is received in Mambu Process Orchestrator (MPO). Bacs' Direct Credit process uses a push method for accepting and depositing payments. When a Service User Number (SUN) holder wants to send money to a payer account (Mambu account), the payer account should be able to accept money in their deposit accounts from the Bacs scheme via ClearBank.

In order to initiate a Bacs Direct Credit payment, the payer needs to know the Sort Code, Account Number, and the name of the account in which the funds should be transferred (the payee). Bacs payments work on a three-day cycle, where the earliest date that the payee will receive a payment is two working days after it is submitted.

Bacs Direct Credits three-day cycle (consecutive working days):

• Day 1: Input Day (entry date), when the payment is submitted.
• Day 2: Processing Day and Contra Entry (processing date), when the BacsDirectCreditInboundPaymentCreated webhook is sent by ClearBank.
• Day 3: Entry day (value date), when the TransactionSettled webhook sent by ClearBank (Credit) and is followed by a Deposit transaction in Mambu.

Standard Bacs Direct Credit transactions are identified by transaction code 99 in the Bacs input record.

Bacs' Direct Credit acts like a Direct Deposit or a Bank Transfer. Therefore, in Mambu a deposit transaction is logged using a dedicated Transaction Channel based on the payment scheme: CB_Deposit_Bacs. This flow can be executed using any Mambu deposit product type for which Deposit transaction can be posted.

The transaction codes that indicate a Direct Credit transaction are:

• 99 – Bacs Direct Credits
• Z4 – Interest payments
• Z5 – Dividend payments
• 86 – Settlement Credits
• 17 – Credit contract (a debit record to balance credit record)

For negative cases, where a payment is settled and the TransactionSettled webhook is sent by ClearBank on Day 3, but due to other issues the Deposit transaction is not posted in Mambu, the return process is initiated using as return code: 0 - Refer to payer and a notification is sent based on the Notification Setup configuration. If the return process fails a notification is sent.

If a Deposit transaction needs to be manually posted in Mambu, transaction channel CB_Deposit_Bacs should be used since the payment is already completed in ClearBank. Otherwise, if the transaction needs to be returned, it should be manually returned using the ClearBank UI - and only on Day 3.

When property confirmationOfPayee is set to true in ClearBank config, the following validation is made:

• Only when Mambu Client Name equals to ClearBank Transaction Owner Name the Direct Credit payment is processed, otherwise, if confirmationOfPayee is set to false this validation is skipped (applies only for Client entities). If the Mambu Client Name is different to ClearBank Transaction Owner Name the Direct Credit payment is returned.
• Regardless of the value of the parameter confirmationOfPayee, if the Mambu Client Name | Group Name is different to ClearBank Owner Name, the Virtual Account owner is updated in ClearBank with the Mambu Client Name | Group Name (applies for Client and Group entities).

Inbound Direct Credit returns

Direct Credit payments must be submitted with the appropriate transaction code to indicate the type of credit being submitted. If the payment cannot be applied for any reason, the funds will be returned no later than Day 5 (Day 3 of ARUCS) of the Bacs processing cycle.

An Automated Return of Unapplied Credit Service (ARUCS) report will be generated by Bacs advising that the payment has not been applied and providing reasons why. A Direct Credit should only be returned if the item cannot be applied.

Reason codes provided in an ARUCS report may include:

• 0 - Invalid details
• 2 - Beneficiary deceased
• 3 - Account transferred
• 5 - No account
• B - Account closed
• C - Requested by Remitter

Bacs Direct Credit returns (ARUCS) follow Bacs' three-day cycle:

• Day 1: Input Day, when the webhook BacsDirectCreditReturnCreated is sent by ClearBank.
• Day 2: Processing Day and Contra Entry.
• Day 3: Entry day
  • success: The webhook TransactionSettled is sent by ClearBank (Debit) followed by Withdrawal transaction in Mambu.
  • failure: The webhook BacsCreditPaymentNotSettled is sent by ClearBank (due to, for example Contra not received).

Automatic returns

ClearBank returns a Direct Credit unapplied if the destination account is unknown, is disabled, or cannot accept credits.

The BacsDirectCreditReturnCreated webhook is sent by ClearBank on Day 3 and the payment is re-routed to the Bacs Suspense account, which then uses the ARUCS process to return the funds. Since no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 will be acknowledged but will not be followed by any action in the connector. The original TransactionSettled (Credit) transaction sent on Day 3 has already been returned in ClearBank.

When a Direct Credit payment is automatically returned by ClearBank, a notification is sent in MPO based on the Notification Setup configuration in Mambu/Zendesk. The notification is sent with the following message:

Task created due to: Transaction in ClearBank was automatically Returned with:  BacsTransactionId - c3232984-495c-4605-b5ab-55b914a6cd22, TransactionID:
[1d4dd717-c8a9-4c75-9a59-e57ff157d3ed], transaction Identifier Field Ref: 04062670034851AUDDISFILE11040626700348510000000390020200417 and End to End ID:
[c3232984495c4605b5ab55b914a6cd22], SUN: 181115.

Manual returns via API

If a Bacs Direct Credit payment cannot be applied to the destination account - due to, for example, a transferred account - ClearBank sends an ARUCS message to the Service User and the funds will be debited from the Suspense account and credited to the originator.

The ClearBank BacsDirectCreditReturnCreated webhook is sent with the source ClearBank when a return via APIs is initiated on Day 3 (Day 1 of ARUCS) or, in exceptional cases, Day 4 (Day 2 of ARUCS) with the reason code 0 - Refer to payer as to why the payment was unapplied. The ARUCS payments are identified by transaction code RA in the Bacs input record.

Once the return request has been generated, the funds will then transfer to the Bacs Suspense Account. This will trigger a TransactionSettled (Debit) webhook, which is sent on Day 5 (Day 3 of ARUCS). The Contra record will need to be submitted on Day 3 (Day 1 of ARUCS) in which return cycle begins. Credit Contras are debits with a transaction code of 17.

Depending on whether the Contra record has been submitted the following will happen:

• If the Contra record is submitted:
  • ClearBank will receive the record on Day 4 (Day 2 of ARUCS)
  • The BacsCreditContraReceived webhook will be sent
  • By Day 5 (Day 3 of ARUCS), the TransactionSettled webhook will be sent to the originating account and the funds will be debited from the Suspense account and credited to the originator.
  • If a Deposit transaction is created in Mambu, the TransactionSettled (Debit) webhook with the field IsReturned = true sent on Day 5 will trigger a withdrawal transaction in Mambu. This is done using a dedicated Transaction Channel based on the payment scheme: CB_Withdrawal_Bacs.
• If the Contra is not submitted, on Day 5 (Day 3 of ARUCS) the BacsDebitPaymentNotSettled webhook will be sent with a specific transaction code and message.

On initial creation, the status of the Credit Contra is Pending followed by the status Processed in short time. Once the status is changed, the TransactionSettled webhook is received, creating a Debit transaction in the Client Money Account.

If the Deposit transaction cannot be posted to Mambu Deposit Account, due to deposit account state is invalid, a notification is sent based on the Notification Setup configuration and return process is initiated using the return code: 0 - Refer to payer. Since no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 will not be processed. The original Credit transaction has already been returned in ClearBank.

If the funds cannot be credited from Mambu Deposit Account - due to, for example, incorrect date format - a notification is sent based on the Notification Setup configuration. After the notification is analyzed it might need the Deposit transaction to be manually re-posted in Mambu using the transaction channel CB_Deposit_Bacs, since the payment is already done in ClearBank.

Manual returns via UI

Manual returns via the ClearBank Portal UI can be triggered only on Day 3 or when an initial return via ClearBank APIs has failed. The ClearBank BacsDirectCreditReturnCreated webhook is sent when a return via the ClearBank Portal UI is initiated on Day 3 (Day 1 of ARUCS) with a specific reason code explaining why the payment was unapplied. The ARUCS payments are identified by transaction code RA in the Bacs input record.

When a Direct Credit payment is manually returned via ClearBank Portal UI, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk. The following message is attached:

[INFO] A return transaction has been initiated from ClearBank Portal UI for the Direct Credit payment with Bacs Transaction ID: e24e2f64-b781-4a03-b3ad-3d4eca813732, End to End Transaction ID: e24e2f64b7814a03b3ad3d4eca813732 and return reason code 0. The Direct Credit payment was successfully reversed in Mambu by posting a Withdrawal transaction with ID [374707] and encoded key [8a015a8e81141878018114eae365035b].

The BacsDirectCreditReturnCreated webhook will be sent with scheme Bacs, source Portal, and the OriginalBacsTransactionId field which represents the link between the initial TransactionSettled received on Day 3 and the returned transaction. The OriginalBacsTransactionId field is stored in the BACS Return Webhooks from CB UI state diagram from MPO, along with the returnSource and returnReasonCode.

When TransactionSettled - Credit with scheme Bacs is sent on Day 5, a search is initiated for the Deposit transaction in Mambu using the OriginalBacsTransactionId. If a Deposit transaction is found, then it is adjusted by posting a withdrawal transaction in Mambu using the transaction channel CB_Return_BACS. If the Deposit transaction is not found, because it was not created, a notification is sent.

Error handling

If a failure occurs during the execution the following actions will be taken in the connector:

• When the return via APIs in ClearBank is active (Day 3 and/or Day 4 of Bacs cycle): The payment will be returned from MPO using the return code: 0 - Refer to payer and a notification of [INFO] is sent with the failure reason. Inbound Direct Credit transaction in ComplyAdvantage remains Active.
• When the return via APIs in ClearBank is not active (after Day 4 of Bacs cycle): The payment will be manually returned by the client and a notification of [INTERVENTION NEEDED] is sent with the failure reason. Inbound Direct Credit transaction in ComplyAdvantage remains Active.

Inbound Direct Credit Held payment

Following an Inbound Direct Credit Held payment and if the payment is successful, two webhooks will be received: BacsDirectCreditInboundPaymentHeld and TransactionSettled.

The ClearBank webhook BacsDirectCreditInboundPaymentHeld is triggered only when the payment should be monitored or investigated (i.e. Sanction Screening).

The payload of the BacsDirectCreditInboundPaymentHeld webhook is stored in [BACS] HELD payments by ClearBank state diagram in MPO, more specifically in the HELD Transactions state.

The results that can be returned by BacsDirectCreditInboundPaymentHeld webhook are: * False Positive: Payment released - TransactionSettled (Credit). * True Positive: Payment remains under investigation.

If after the analysis, the result is False Positive:

• The payment is automatically released by ClearBank.
• The TransactionSettled webhook is sent (this is matched by the Reference and BacsTransactionId values in ClearBank) and updates the payload in the [BACS] HELD payments by ClearBank state diagram by transitioning from the HELD Transactions state to the Accepted Transactions by ClearBank state.
• The deposit transaction is automatically posted in Mambu.

If after the analysis, the result is True Positive then:

• The payment will be re-routed to the ClearBank Suspense Account until instructions are received.
• The payment is held for 12 hours (until Day 3 of Bacs) and a notification will be sent. Then, the payment in the [BACS] HELD payments by ClearBank state diagram will automatically transition from the HELD Transactions state to the Rejected Transactions by ClearBank state and a notification will be sent.

Inbound Direct Credit Recall

A Bacs Direct Credit may be recalled, to cancel processing of the payment, by the Service User’s Payment Service Provider (PSP) up until 15:45 on Day 2 of the Bacs processing cycle. ClearBank will manage recall requests on the client’s behalf. A recalled Bacs Direct Credit will not be applied to client’s account.

The process is automatically triggered when a Direct Credit payment is recalled from Bacs and webhook BacsDirectCreditRecalled is received in MPO.

Since this means that the Direct Credit payment was cancelled, a notification is sent based on the Notification Setup configuration with the payment details sent from ClearBank with the following message:

Task created due to: BACS Direct Credit Payment was Recalled. Task was created from MPO for: Transaction Type: DirectCredit, Bacs Transaction ID: a761c3f2-c22h-2j7a-228c-b23rf3685c1e, Transaction Status: Recalled, Service User Number: 916201, RecallReference: DCMRCHRECALL for Mambu Creditor with Account Number: 00000192. Process ID: 43967.

Inbound Direct Debit payment

This template allows you to collect payments against a Mambu deposit account from a payer who has completed a Direct Debit Instruction previously using Bacs.

The process is automatically triggered when a Direct Debit payment is initiated from the Bacs system and the webhook TransactionSettled is received in MPO.

Bacs' Direct Debit is a method of collecting or withdrawing payments from a deposit account against a Direct Debit Instruction created before. When a Service User wants to collect a payment from a payer account (Mambu account), the payer account should have sufficient amount in their Deposit account to send the money via ClearBank.

In order to do a Bacs Direct Debit payment, the Service User needs to send the payer’s Sort Code, Account Number, and the SUN number from the DDI with the appropriate transaction code.

The transaction code indicates the status of the Direct Debit collection:

• 01 - For the first collection
• 17 – For the collection of all Direct Debits (standard), i.e. not a first, final or re-presented Direct Debit
• 18 – For re-presentations
• 19 – For final collections
• 99 – Debit contract (a credit record to balance debit record)

This flow can be executed using any Mambu deposit product type for which withdrawal transaction can be executed. Bacs payments work on a three-day cycle, so the earliest date that the Service User will collect a payment is three working days after it is submitted.

Bacs' Direct Debit 3-day cycle (on consecutive working days):

• Day 1: Input Day (entry date), when the Service User submits the payment to Bacs.
• Day 2: Processing Day/Contra Entry (processing date), when the BacsDirectDebitInboundPaymentCreated webhook is received.
• Day 3: Entry day (value date), when the TransactionSettled webhook is received (Debit) followed by Withdrawal transaction in Mambu.

Standard Bacs Direct Debit transactions are identified by transaction code 17 in the Bacs input record.

For negative cases, where the payment is settled and the TransactionSettled webhook is sent by ClearBank, but the withdrawal transaction was not posted in Mambu, the return process is initiated using the return code: 0 - Refer to payer and a notification is sent based on the Notification Setup configuration. If the return process is not started after the notification is analysed and payments details are known, then the withdrawal needs to be manually posted in Mambu using the CB_Withdrawal_Bacs transaction channel - since the payment is already done in ClearBank. Otherwise, if the transaction needs to be returned, it should be manually returned using the ClearBank UI.

Outbound Direct Debit Indemnity Claim

A Direct Debit Indemnity Claim (DDIC) is a claim made by the paying bank in respect of an incorrect Direct Debit collection applied to a customer account. The paying banks have to refund the payer in the event of an error by the service user (originator) or the bank. An indemnity claim can only be raised for the full amount.

Paying banks then use the Indemnity Claim process to recover the refunded payment from the service user. Indemnity Claim are raised using the automated process Direct Debit Indemnity Claim Automation (DDICA). Subject to the exceptions detailed below all indemnity claims are processed via the automated route: • Indemnity claims of £125,000* or more • The Service User Number (SUN) is no longer recorded on the Bacs system • Claims for consequential loss

All indemnity claims, whether received via the automated system or the paper exceptions process, must be settled within 14 working days of the date of the claim. Service users must take no action to settle indemnity claims received via the automated route as settlement will occur automatically 14 working days after the indemnity claim was submitted.

The Direct Debit Guarantee is unlimited as to time and amount and paying bank will raise an indemnity claim where an error has been made, by the service user, in the collection of a Direct Debit.

A valid indemnity claim must meet one of the criteria listed in the following list:

• The amount and/or date of the Direct Debit differ from the Advance Notice issued to the payer by the service user
• No Advance Notice was received by the payer
• Direct Debit Instruction (DDI) cancellation by the paying bank. Where there is proof that a Bacs' Automated Direct Debit Amendment and Cancellation Service (ADDACS) has been sent by the paying bank to the service user on or before the debiting day
• Payer has cancelled the Direct Debit Instruction direct with the service user, notwithstanding the fact that the payer may not have cancelled the Direct Debit Instruction with the paying bank
• A payer disputes having given authority
• Signature on Direct Debit Instruction is fraudulent or not in accordance with the account authorised signature(s) held by the paying bank
• An indemnity claim raised at the service user’s request. The request will not be accepted by the paying bank until after payment has been debited to the payer’s account. No action will be taken on any request until it has been confirmed in writing to the paying bank (e.g. by fax / email). Details of the confirmation will be submitted with the indemnity claim.
• Payer does not recognise the service user collecting Direct Debit. Where the paying bank is unable to identify and consequently action a payer’s request to cancel a Direct Debit Instruction as a result of the service user using one of the set-up exceptions in respect of trading names or facilities management.

(https://swimlanes.io/u/xdI2--ca2)

When an indemnity claim is accepted, a TransactionSettled webhook with Transfer scheme is sent by ClearBank in 14 working days of the date of the claim. This webhook will be processed and in MPO [BACS] Indemnity Claim (Adjust Withdrawal) process is triggered which will post a Deposit transaction in Mambu by using a dedicated Transaction Channel based on the payment scheme: CB_Return_Bacs, and a [INFO] notification is sent.

Inbound Direct Debit returns

A Direct Debit transaction can be returned if there are insufficient funds in the Virtual Account or if there is an Instruction from the customer not to pay a transaction. If the payment cannot be applied for any reason, the funds will be returned no later than Day 5 (Day 3 of ARUDD) of the Bacs processing cycle.

Bacs' Automated Return of Unpaid Direct Debit (ARUDD) follows the Bacs three-day cycle:

• Day 1: Input Day, when the webhook BacsDirectDebitReturnCreated is sent by ClearBank.
• Day 2: Processing Day and Contra Entry.
• Day 3: Entry day:
  • success: The TransactionSettled webhook is sent by ClearBank (Credit), followed by the Deposit transaction in Mambu.
  • failure: The BacsDebitPaymentNotSettled webhook sent by ClearBank (due to, for example Contra not received).

An ARUDD report will be generated by Bacs advising that the payment has not been applied and providing reasons why.

ARUDD reason codes:

• 0 - Refer to payer
• 1 - Instruction cancelled
• 2 - Payer deceased
• 3 - Account transferred
• 4 - Advance notice disputed
• 5 - No account (OR wrong account type)
• 6 - No Instruction
• 7 - Amount differs
• 8 - Amount not yet due
• 9 - Presentation overdue
• A - Service user differs
• B - Account closed

Automatic returns

ClearBank returns a Direct Debit unpaid if:

• The account does not exist.
• The Client Money Account is disabled or does not accept debits.
• There is no Direct Debit Instruction matching the collection request.
• There are insufficient funds in the Client Money account associated with the Virtual account.

If a transaction is returned, a BacsDirectDebitReturnCreated webhook is sent by ClearBank and the payment is re-routed to Bacs Suspense account and then the ARUDD process is used to return the funds.

When a Direct Debit payment is automatically returned by ClearBank, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: Transaction in ClearBank was automatically Returned with: BacsTransactionId - 7244716a-0487-4593-b24d-20b74a252a61, TransactionID: [e08a08b7-2c0e-4aec-8fae-cfe4759bdba4],
transaction Identifier Field Ref: 04062687167050MOREFUN2040626871670500000007500020200414 and End to End ID: [7244716a04874593b24d20b74a252a61] for Debit mandate ID: [91421kjad4d570c476550170d35fe2481514]
with SUN: 520155. Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectDebit. Process ID: 705941.

Manual returns via API

If a Bacs Direct Debit payment cannot be applied to the destination account, ClearBank sends an ARUDD message to the Service User and the funds will be credited from the Suspense account and debited to the originator.

The ClearBank BacsDirectDebitReturnCreated webhook is triggered when a return is initiated on Day 3 (Day 1 of ARUDD) and sent to MPO with an appropriate reason code as to why the payment was unpaid. The ARUDD payments are identified by the following transaction codes:

The ClearBank BacsDirectDebitReturnCreated webhook is triggered when a return is initiated on Day 3 (Day 1 of ARUDD) and sent to MPO with an appropriate reason code as to why the payment was unpaid. The ARUDD payments are identified by the following transaction codes:

• U1 - Return of Unpaid DD – First Collection
• U7 - Return of Unpaid DD – Regular Collection
• U8 - Return of Unpaid DD – Re-Presented
• U9 - Return of Unpaid DD – Final Collection

Once the return request has been generated, the funds will transfer to the Bacs Suspense Account, which will trigger a TransactionSettled (Credit) webhook. The Contra record will need to be submitted on Day 3 (Day 1 of ARUDD) of the return cycle. Debit contras are credits with a transaction code of 99.

Depending on whether the Contra record has been submitted the following will happen:

• If the Contra has been submitted:
  • ClearBank will receive the record on Day 4 (Day 2 of ARUDD).
  • The BacsDebitContraReceived webhook will be sent.
  • By Day 5 (Day 3 of ARUDD), the TransactionSettled webhook will be sent to the originating account and the funds will be credited from the Bacs Suspense Account and debited to the originator.
  • In MPO process Inbound Direct Credit - Deposit [API] process is automatically triggered and a Deposit transaction is posted using a dedicated Transaction Channel based on the payment scheme: CB_Deposit_Bacs.
• If the Contra is not submitted, on Day 5 (Day 3 of ARUDD) BacsCreditPaymentNotSettled webhook will be sent with a specific transaction code and message.

If the notification is set to true then a task will be created in Mambu or ZenDesk based on the configuration Notification Setup with an error message to analyze.

On initial creation, the status of the Debit Contra is Pending followed by the status Processed in short time. Once the status is changed, the TransactionSettled webhook is received, creating a Credit transaction in Client Money Account. This webhook will trigger in MPO the Inbound Direct Credit - Deposit [API] process which will create a Deposit transaction in Mambu for correspondent deposit account.

If the withdrawal transaction in Mambu cannot be posted due to insufficient funds or an invalid deposit account state, the account holder requests the paid debit to be returned via API using the return code: 0 - Refer to payer. Since no corresponding Withdrawal (Debit) transaction exists in Mambu, the TransactionSettled (Credit) webhook sent by ClearBank will not be processed, as the original Debit transaction is processed only in ClearBank.

If the funds cannot be debited from Mambu Deposit Account due to, for example, incorrect date format, a notification is sent based on the Notification Setup configuration. After the notification is analyzed it might need that the Withdrawal transaction be manually re-posted in Mambu using transaction channel CB_Withdrawal_Bacs since the payment is already done in ClearBank.

Manual returns via UI

Manual returns via the ClearBank Portal UI can be triggered on demand only on Day 3 or when an initial return via ClearBank APIs has failed. The ClearBank BacsDirectDebitReturnCreated webhook is sent when a return via the ClearBank Portal UI is initiated on Day 3 (Day 1 of ARUDD) with a specific reason code explaining why the payment was unapplied. The ARUDD payments are the same as mentioned in the Manual Returns via APIs section.

When a Direct Debit payment is manually returned via the ClearBank Portal UI, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

[INFO] A return transaction has been initiated from ClearBank Portal UI for the Direct Debit payment with Bacs Transaction ID: e24e2f64-b781-4a03-b3ad-3d4eca813732, End to End Transaction ID: e24e2f64b7814a03b3ad3d4eca813732 and return reason code 0. The Direct Debit payment was successfully reversed in Mambu by posting a Withdrawal transaction with ID [374707] and encoded key [8a015a8e81141878018114eae365035b].

The BacsDirectDebitReturnCreated webhook will be sent with scheme Bacs, source Portal, and OriginalBacsTransactionId field, which represents the link between the initial TransactionSettled received on Day 3 and the returned transaction. The OriginalBacsTransactionId field is stored in the BACS Return Webhooks from CB UI state diagram in MPO, along with the returnSource and returnReasonCode. When TransactionSettled - Credit with scheme Bacs is sent on Day 5, the Withdrawal transaction is first searched in Mambu by the OriginalBacsTransactionId. If a Withdrawal transaction is found it is adjusted by posting a Deposit transaction in Mambu using the transaction channel CB_Return_BACS. If the Withdrawal transaction is not found, due to the fact it was not created, a notification is sent.

Error handling

In case of Direct Debit failures, there can be two different outcomes depending on the value of the returnDirectDebitTransaction parameter in the ClearBank config:

• When the value of the returnDirectDebitTransaction parameter is set to true and:
  • The return via APIs in ClearBank is active (Day 3 and/or Day 4 of Bacs cycle): The payment will be returned from MPO using the return code 0 - Refer to payer and an [INFO] notification is sent with the failure reason.
  • The return via APIs in ClearBank is not active (after Day 4 of Bacs cycle): The payment will be manually returned by the client and a notification of [INTERVENTION NEEDED] is sent with the failure reason.
• When the value of the returnDirectDebitTransaction parameter is set to false: The Direct Debit transaction will be returned only if the Mambu deposit account is in an invalid state or has insufficient funds. Otherwise, only a notification will be sent with the failure reason and, on Day 3, the payment will be processed. Manual intervention may be needed if a failure occurs.