Testing Direct Debit Payments

In your demo environment, create a test payment with the following data:

1. Payer information (Magic Values)

Use any placeholder data you'd like for the required payer information like first name, last name etc.

For the payer's first name use one of the magic values depending on the scenario you want to test:

Successful Payment - realistic disbursement

This scenario simulates a realistic disbursement. Instead of advancing immediately, payments created with this magic value are held in Guaranteed until they get "disbursed" - which means they move to Delivered daily at 4:00 PM UTC (Monday through Friday). If you create multiple test payments with this value, you create a realistic disbursement file that contains multiple payments.

This magic value can be used for all payment methods.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_GUARANTEED_STATUS

Initiated → Processed → Guaranteed → moved daily at 4:00 PM UTC (Monday through Friday) Delivered

image Initiated

image Processed

image Guaranteed

After moving to delivered - happens daily at 4:00 PM UTC (Monday through Friday):

image Delivered

Successful Payment - disbursed immediately

This magic value moves a payment into delivered immediately. This magic value can be used for all payment methods.

Be aware that this is not a realistic payment behavior and creates disbursement files that contain only one payment, since every time a payment is moved to Delivered a new disbursement file is generated. Usually, all payments for the day get bundles into one disbursement file.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_DELIVERED_STATUS

Initiated → Processed → Guaranteed → Delivered

image Initiated

image Processed

image Guaranteed

image Delivered

Unsuccessful Payment - cancelled payment

This scenario simulates a cancelled payment. This magic value can be used for all payment methods.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_CANCEL_STATUS

Initiated → Cancelled

image Initiated

image Cancelled

Successful Payment - with simulated successful verification

This magic value simulates a payment that fails automated checks and gets routed to manual review which ends up being successful. This can happen for any payment method if a manual review (for example document collection or quality checks) is necessary.

The manual compliance review time is simulated as 2 hours, but note that the actual duration on a real compliance review differs depending on the necessary reviews.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_VERIFICATION

Initiated → Processed → after 2 hours Guaranteed → moved daily at 4:00 PM UTC (Monday through Friday)Delivered

image Initiated

image Processed

After 2 hours:

image Guaranteed

After moving to delivered - happens daily at 4:00 PM UTC (Monday through Friday):

image Delivered

Unsuccessful Payment - with simulated failed verification

The magic value simulates a payment that fails automated checks and gets routed to manual review and fails the check. This can happen for any payment method if document collection or quality checks fail and cannot be manually corrected by contacting the payer.

The manual compliance review time is simulated as 2 hours, but note that the actual duration on a real compliance review differs depending on the necessary reviews.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_VERIFICATION_FAILED

Initiated → Processed → after 2 hours Cancelled

image Initiated

image Processed

After 2 hours:

image Cancelled

Reversed Payment

This scenario is only for direct debit payments.

This payment flow can happen when a direct debit payment remains unpaid: 

  • The direct debit payment went into the delivered status (which means you received the funds from Flywire).

  • Then the direct debit payment fails and remains unpaid (which means Flywire did not receive the funds).

    A direct debit payment can fail when it was initiated but the Flywire partner (for example, the bank) could not retrieve the funds from the payer's bank account, which means the payment remains unpaid and Flywire doesn't receive the funds. There can be different reasons for this, for example due to insufficient funds, payment was cancelled by the bank, account is closed, wrong account number, payer cancelled the payment, etc.

  • Then Flywire will start a recovery process and the payment status will change from delivered to reversed.

 

Payer's First Name Payment Flow Callbacks you will receive

SANDBOX_TO_REVERSED_STATUS

Initiated → Processed → Guaranteed → Delivered → Reversed

image Initiated

image Processed

image Guaranteed

image Delivered

image Reversed

2. Payment option

Choose a direct debit payment option. Enter the following demo bank account data:

BACS

Sort Code 60 00 01
Account Number 00000019

SEPA

EEA Country

Country Spain
IBAN ES7921000813610123456789

Non-EEA Country

Country United Kingdom
IBAN GB98MIDL07009312345678
BIC BOFIIE2D

3. Check the results

You will receive callbacks according to the scenario you chose (see Payment Status Notifications for details).

You will also receive payment information via returnUrl or OnCompleteCallback handler, depending on which one you are using (see After-Payment Settings for details).