This FAQ is provided as a complement to the rest of this SCA documentation and our email communications.

If your query is not addressed below or in the docs, please get in touch with our teams via the Dashboard.

​
Is the phone number mandatory for us? How should we handle existing phone number data?

A phone number is mandatory for SCA but in the API it is optional. Your users can conveniently provide their phone number when they are redirected to the Mangopay-hosted webpage to enroll in SCA. If you wish, you can provide it via the API to pre-populate the field in on the page (read more).

​
If a user’s phone number is associated with another account, will they be blocked or prevented from enrolling in SCA?

No. Our system is designed to efficiently manage phone number associations.

​
If a user refreshes the hosted webpage or doesn’t receive the SMS, can it be resent?

Yes. If the user refreshes the page, or closes and re-opens the same link, they will remain on the OTP verification screen. The feature is designed to give users control over when they receive an OTP, ensuring that the process is transparent and efficient for them.

​
If a KYC/KYB document is refused due to data mismatch, can we modify the data on behalf of our users or do we need to contact them?

Only modifications to phone number and email require validation through SCA by the end user. SCA has no impact on the existing KYC processes surrounding documents or the downgrade mechanism.

​
Can we delay enrollment if we create the user when they are not present on our website or app?

No, it is generally not possible to delay SCA enrollment when the OWNER is created (or categorized as such). In the user endpoints, there is no functionality similar to the ScaContext and USER_NOT_PRESENT value being added to transfers and wallet access, because there are no exemptions for account creation.

However, in certain cases we may grant an exemption to this situation if your workflow was built using automated user object creation. In such cases, it is essential that your app or website offers an option for your users to complete their SCA enrollment using the dedicated POST Enroll a User endpoint at the appropriate time.

Please begin integrating the user-related endpoints for legal users. Soletraders, as individuals, are already able to use the SCA feature. For businesses and other types of Legal user, Mangopay is developing features to introduce SCA with as little friction as possible. This may include as allowing users to define authorized individuals who can complete SCA on behalf of the entity. The new functionality will allow designated authorized individuals within a legal entity to perform SCA, rather than limiting this capability solely to the declared legal representative.

See the guide section on legal user integration →

​
We already have SCA or MFA on our website or app. Can we use our existing feature and send validation to Mangopay through the API?

No. Applicable regulations require Mangopay to perform SCA directly with users that have a Mangopay account.

​
What are the specific actions that require SCA?

SCA has an impact on OWNER users at certain moments of their activity with Mangopay. Your platform must change its implementation as a result (see integration required for SCA).

Prior to being able to authenticate actions, the user must:

  • Enroll at Mangopay Account creation (when a user is assigned the OWNER UserCategory)
  • Re-enroll if their contact details change (Email, PhoneNumber)

The actions taken by OWNER users that require SCA to be performed are:

  • Bank account registration (by OWNER users for use with payouts)
  • Transfer initiation (between two OWNER users)
  • Mangopay Account access by OWNER users to view wallet balance or list transactions

For more details, see the guides.

​
What should we expect regarding SCA for transfers between Mangopay wallets?

Only transfers initiated directly by your end users will require SCA. Automated or programmed transfers for technical purposes in workflows should not be impacted by SCA requirements, provided that end-users are made aware of transfers triggered on their behalf in your T&Cs. It will also be possible to exempt low-risk and low-amount transactions, again as per the possible regulatory exemptions.

For more details, see the transfers guide.

​
For SCA-applicable actions not taken by the user, but rather as part of automated workflows, will SCA be required?

For existing integrations, platforms will be able to identify actions not taken by the user thanks to the USER_NOT_PRESENT value of the new parameter ScaContext. These requests will not initially require SCA redirection.

Over time, Mangopay will analyze the adoption of SCA and may be required to take appropriate action to ensure compliance. Mangopay’s objective is to protect your users when they benefit from our services, via an authentication solution that is easy for your platform to adopt in its existing integration.

For more details, see the transfers guide.

​
What happens if we perform actions on behalf of users, without their direct involvement?

The USER_NOT_PRESENT value for ScaContext allows platforms to identify actions where SCA redirection will not be immediately required.

The use of this feature for actions taken on behalf of users, without their direct involvement, may be possible if the platform can demonstrate that it has the legal capacity to perform an action falling within the scope of the SCA on behalf of a third party. This legal capacity may result, for example, from a contractual arrangement (such as a mandate or representation contract) or another specific legal provision that would authorize the platform to act in this way.

We remain committed to maintaining the highest standards of security and compliance, and Mangopay will analyze such cases over time to determine the appropriate SCA arrangement.

​
When will SCA be triggered for our existing users, and how will it work?

For existing users, Mangopay’s features allow your platform to enroll them at a convenient point in their journey using the dedicated POST Enroll a User endpoint.

SCA is be applied when the user takes an action requiring SCA.

For more details, see existing user integration.

​
Will the legacy user endpoints be maintained? How long for until deprecated?

The legacy user endpoints should not be integrated for new platforms. In this sense, the should already be considered deprecated because they are redundant with the new ones (even for Legal Business, Partnership, and Organization).

Mangopay plans to decommission these endpoints in Q1 2026 to make them no longer available.

​
Will the legacy bank account endpoints be deprecated?

Yes, the bank account feature will also be removed in mid-2026. Mangopay is releasing a new Recipients feature which completely replaces bank accounts. Once Recipients is live in Production, the bank accounts endpoints should no longer be used. The Bank Account endpoints will become unavailable in mid-2026.

​
Will we have to re-register bank accounts as Recipients?

No. You can continue using existing bank accounts (BankAccountId) for payouts.

​
Can we do SCA with the user later if it’s triggered by an action initiated on their behalf?

No, the SCA session starts immediately when the action is triggered. The user has 10 minutes to complete the authentication on the hosted webpage before the session expires.

​
Will users be restricted if a user is not enrolled in SCA?

Initially, existing users are not restricted by the introduction of SCA.

existing users, who already have ACTIVE as their UserStatus, will not be restricted or transitioned to PENDING_USER_ACTION if you attempt to enroll them using POST Enroll a User and the SCA session is not successful.

On Recipients, Transfers, and Account Access they will also not be restricted (their status remains ACTIVE), but the relevant action will not succeed. In this case, you need to retry the Recipient creation or Transfer to allow the user to complete SCA successfully.

Mangopay may be required to start introducing consequences on users if they haven’t enrolled in SCA, but this will be done with sufficient notice to platforms. You will also be informed of the consequences of non-enrollment, which may include removing certain permissions, blocking the account, reverting the category to PAYER, or closing the account.

Mangopay’s objective is to protect your users when they benefit from our services, via an authentication solution that is easy for your platform to adopt in its integration. We remain committed to maintaining the highest standards of security and compliance.

See the guide section on existing user integration →

​
If a user completes SCA enrollment and then registers a new Recipient (external account), will they need to authenticate again?

Yes. It may be possible to use the same session if the external account is in the same name as the user.

​
Is SCA implementation compulsory for us?

Yes, it is a regulatory obligation imposed by the PSD2 directive with the purpose of protecting you and your users against fraud and abuse. As a payment service provider (PSP), it’s our role to protect your users from credential attacks and account takeovers by verifying their identities and ensuring the legitimacy of their actions.

​
What happens if we don’t integrate the new endpoints? What are the consequences for us?

Implementation of SCA is mandatory. Failure to integrate the new endpoints exposes your users to fraud and abuse and would prevent us from providing payments services to them, as outlined in our terms and conditions.

​
Can we get an extension to the deadline?

No. SCA is a regulatory requirement for Mangopay Account holders. We will require you to undertake the integrations outline in our documentation and by the dates communicated. If you have any concerns about the deadline or integration timelines, please contact our teams via the Dashboard.

​
Do we need to sign a contract amendment?

No, you will not be required to sign any contract amendment – our existing contract remains in effect.

​
We have a Merchant Agreement. How will SCA impact us?

For platforms operating under a Merchant Agreement, SCA will be integrated as part of our ongoing commitment to regulatory compliance. While implementing SCA is mandatory, we are dedicated to supporting you through the transition and ensuring a smooth experience. Detailed guidance on the specific impacts will be provided shortly.

​
We use the Mirakl Connector. How will SCA impact us?

Mangopay is improving its Mirakl Connector to enable SCA during the vendor onboarding process. We will communicate changes required in due time. Until then, no action is required for SCA.

​
We use the WordPress plugin. How will SCA impact us?

Mangopay will provide further information about the WordPress plugin in due course.

​
We have a specific workflow. Can we get an exemption?

The changes being brought to the Transfer feature will allow platforms to declare automated transfers that do not require SCA by the end user. This feature will therefore allow your platform to implement your declared and authorized workflow in agreement with Mangopay.

​
What should we say to our end users or customers who are asking us why we’re requiring them to perform SCA?

You can convey to your end users that their security is being strengthened through the implementation of strong customer authentication (SCA) on your platform as per regulatory requirements. This enhanced security measure provides additional protection against account takeovers resulting from phishing attempts, credential attacks, and personal data breaches. By adopting SCA, you are not only prioritizing their safety but also ensuring compliance with the latest regulatory standards. You can assure your end users that you and Mangopay remain committed to delivering a secure and seamless experience.