Skip to navigation
ResourcesTesting

Testing overview

Mangopay’s Sandbox API environment aims to mirror the Production environment as closely as possible.

There are some cases where Mangopay provides dedicated Sandbox features to facilitate your testing, for example by removing manual steps or by simulating real-world events.

This page gives an overview of the testing features available along a typical user and payment lifecycle.

Note that some of these testing functionalities were previously only available via the Sandbox Operations in the Mangopay Dashboard, but the API-based features below replace these.

Pay-ins

To initiate a pay-in, you need:

  • A Natural User or Legal User (who is the pay-in’s AuthorId)
  • A Mangopay wallet to which the funds are credited (pay-in’s CreditedWalletId)

The User can have the UserCategory of PAYER. The OWNER category indicates that they have a Mangopay Account, involving SCA enrollment (see below).

Cards

Mangopay provides test cards that you can use in all card pay-in flows: one-time, recurring, preauthorizations, and extended preauthorizations.

Mangopay provides cards of different brands and for use in 3DS challenge or frictionless scenarios. See the card testing data for the specific numbers to use.

APMs

For Mangopay’s wide offering of APMs, see the guidance under each payment method.

Bank wires

Pay-in to Virtual Account

Mangopay can provide a Virtual Account, such as an IBAN or other account identifier, that is attached to a user’s wallet. When funds are received on the account, they are credited to the wallet.

Once you have set up a Virtual Account, you can use POST Simulate a bank wire funding notification to simulate the arrival of the funds. For more details, see the guidance on testing a bank wire pay-in to a Virtual Account.

Pre-declared pay-in to a pooled Mangopay account

Mangopay can also receive bank wires to a pooled Mangopay account, which are then reconciled and credited to the user’s wallet. This pay-in needs to be declared in advance of the funds being sent by the user with their bank, using POST Create a Bank Wire PayIn.

Once the pay-in is declared, you can use POST Simulate execution of a Bank Wire PayIn to simulate the user’s action of wiring the funds. For more details, see the guidance on testing a bank wire pay-in to a pooled Mangopay account.

Pay by Bank

Mangopay’s open banking solution, Pay by Bank, allows you to redirect a user to initiate the payment directly with their bank all within the checkout flow.

For more details, see the guidance on testing Pay by Bank.

Direct debit

Mangopay offers two direct debit schemes: SEPA Direct Debit and Bacs (UK). See the dedicated guidance for information on testing these flows.

SCA on users

A Natural User or Legal User with the UserCategory of PAYER can be the AuthorId of a pay-in and initiate transfers out of their wallet.

The OWNER category, on the other hand, indicates that the user holds a Mangopay Account, because these users accept and are bound by Mangopay’s terms and conditions (T&Cs) and are being provided with Mangopay payment and/or e-money services.

To create a Mangopay Account, the user must enroll in Mangopay’s SCA.

Proxy management system

Some platforms, due to their activity and integration workflow, may wish to take actions on behalf of users in certain circumstances. It is possible for your platform to perform an SCA-triggering action on behalf of a user, but Mangopay must ensure that the user consents.

Mangopay offers a way to manage that proxy and consent for SCA-triggering action scopes, and you can test proxy management in Sandbox by contacting Mangopay to activate it. However, the SCA bypasses mentioned below are only possible when proxy management is not activated.

Bypass SCA on user creation and update

In Sandbox, you can test Mangopay’s SCA functionality as it behaves in Production. You can also bypass SCA to facilitate testing.

On the following endpoints:

You can bypass SCA by including the word accept in the email address used for SCA, which is:

  • Email for a Natural User
  • LegalRepresentative.Email for a Legal User

For example accept@example.com or accept+john.doe@example.com.

The accept bypass also applies to the following PUT calls, which otherwise only trigger SCA when they modify SCA-controlled data (PhoneNumber, PhoneNumberCountry, or Email — see SCA triggers in Sandbox for details):

SCA on wallets

SCA is required for OWNER users to view data about their wallet balances.

If the OWNER user’s email contains accept as described above, then the following calls don’t trigger SCA even with ScaContext set to USER_PRESENT:

Instead of the 401 with WWW-Authenticate header, a 200 is returned. See SCA triggers in Sandbox for the full conditions.

SCA on transfers

SCA is required on a transfer from a wallet held by an OWNER if it is above 500 EUR and not exempted for being low risk.

If the OWNER user’s email contains accept as described above, then such transfers don’t trigger SCA on the following endpoint:

Instead, the transfer succeeds and PendingUserAction is not returned. See SCA triggers in Sandbox for the full conditions.

SCA on recipients

Bypass SCA on recipient creation

If the OWNER user’s email contains accept as described above, then a call to the following endpoint doesn’t trigger SCA even with ScaContext set to USER_PRESENT and RecipientScope set to PAYOUT – the PendingUserAction.RedirectUrl is not returned and the Recipient passes to ACTIVE automatically:

See SCA triggers in Sandbox for the full conditions.

KYC/KYB verification

An OWNER User must be KYC/KYB verified before being able to exceed the limits imposed on them, such as being able to request a payout to their external bank account.

Mangopay’s hosted frontend experience for KYC/KYB is available in Sandbox by following the HostedUrl returned by the following endpoint:

In the Sandbox experience, a selector allows you to simulate certain options, such as a match (or not) against a business registry for Business-type verification — see testing hosted KYC/KYB for details.

You can also bypass the verification process entirely by setting the Tag parameter to VALIDATED, which forces the session directly to that Status without completing the hosted flow. You can also force the session to the other statuses by setting the Tag in the same way to REFUSED, REVIEW, or EXPIRED.

Payouts

To test a successful payout, ensure the Recipient’s Status is ACTIVE (see SCA on recipients above), and that the user’s KYCLevel is REGULAR, then call:

Payouts on Sandbox test accounts succeed automatically. To test a FAILED payout, you need to trigger a technical error such as setting the amount as greater than the wallet balance, or by using an unverified user.

For more guidance, see testing payouts →.