> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.mangopay.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server. # 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](#sca-on-users)). ### Cards Mangopay provides test cards that you can use in all card pay-in flows: [one-time](/guides/payment-methods/card/direct), [recurring](/guides/payment-methods/card/recurring), [preauthorizations](/guides/payment-methods/card/preauthorization), and [extended preauthorizations](/guides/payment-methods/card/extended-preauthorization). Mangopay provides cards of different brands and for use in 3DS challenge or frictionless scenarios. See the [card testing data](/testing/payment-methods#cards) for the specific numbers to use. ### APMs For Mangopay's wide offering of APMs, see the guidance under each [payment method](/testing/payment-methods#alternative-payment-methods-apms). ### 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](/api-reference/simulation/simulate-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](/testing/payment-methods#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](/api-reference/bank-wire-payins/create-bank-wire-payin). Once the pay-in is declared, you can use [POST Simulate execution of a Bank Wire PayIn](/api-reference/simulation/simulate-execution-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](/testing/payment-methods#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](/testing/payment-methods#pay-by-bank). ### Direct debit Mangopay offers two direct debit schemes: SEPA Direct Debit and Bacs (UK). See the dedicated [guidance](/testing/payment-methods#direct-debit) 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](/guides/sca/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: * [POST Create a Natural User (SCA)](/api-reference/users/create-natural-user-sca) * [POST Create a Legal User (SCA)](/api-reference/users/create-legal-user-sca) * [PUT Categorize a Natural User](/api-reference/users/categorize-natural-user) * [PUT Categorize a Legal User](/api-reference/users/categorize-legal-user) 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](/guides/sca/users#sca-triggers-in-sandbox) for details): * [PUT Update a Natural User (SCA)](/api-reference/users/update-natural-user-sca) * [PUT Update a Legal User (SCA)](/api-reference/users/update-legal-user-sca) ## 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](#bypass-sca-on-user-creation-and-update), then the following calls don't trigger SCA even with `ScaContext` set to `USER_PRESENT`: * [GET View a Wallet](/api-reference/wallets/view-wallet) * [GET List Wallets for a User](/api-reference/wallets/list-wallets-user) * [GET List Transactions for a User](/api-reference/transactions/list-transactions-user) * [GET List Transactions for a Wallet](/api-reference/transactions/list-transactions-wallet) Instead of the 401 with `WWW-Authenticate` header, a 200 is returned. See [SCA triggers in Sandbox](/guides/sca/wallets#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](#bypass-sca-on-user-creation-and-update), then such transfers don't trigger SCA on the following endpoint: * [POST Create a Transfer](/api-reference/transfers/create-transfer) Instead, the transfer succeeds and `PendingUserAction` is not returned. See [SCA triggers in Sandbox](/guides/sca/transfers#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](#bypass-sca-on-user-creation-and-update), 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: * [POST Create a Recipient](/api-reference/recipients/create-recipient) See [SCA triggers in Sandbox](/guides/sca/recipients#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: * [POST Create an IDV Session](/api-reference/idv-sessions/create-idv-session) 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](/guides/users/verification/hosted#tag-based-bypass) 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](#sca-on-recipients) above), and that the user's `KYCLevel` is `REGULAR`, then call: * [POST Create a Payout](/api-reference/payouts/create-payout) 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](/testing/payouts) **→**.