Introduction to SCA

Strong customer authentication (SCA) was introduced under the revised EU Payment Services Directive (PSD2) to all kinds of financial institutions and payment service providers (PSP). It is a form of multi-factor authentication (MFA, also 2FA), where a user authenticates using evidence of different categories (knowledge, possession, and inherence). As a regulated electronic money institution (EMI), Mangopay is introducing SCA for the end users of your platform who hold a Mangopay Account. Our SCA solution allows your platform to protect users’ funds and payment activity via a Mangopay-hosted experience.

​

Scope

Mangopay’s SCA features are applicable to Natural Users and Legal Users whose UserCategory is OWNER. Owner users are subject to Mangopay’s T&Cs and as such hold a Mangopay Account. The regulations require these account holders to perform SCA directly with Mangopay. Users whose UserCategory is PAYER are not affected by Mangopay’s SCA features, but see the note below about SCA with their issuers on pay-ins. For information and users whose UserCategory is PLATFORM, see below.

​

Actions requiring SCA

The regulations require Mangopay to apply SCA to situations where a OWNER user accesses their payment account or initiates certain payment activities, or to other situations considered at risk. The SCA-triggering actions impact OWNER users at certain moments of their activity with Mangopay.

​

SCA enrollment

Prior to being able to authenticate actions, there are two actions relating to enrollment in SCA:

• SCA enrollment at the point of Mangopay Account creation, which is when a user is assigned the OWNER value for UserCategory
• Re-enrollment if the user’s SCA contact details change, meaning their email and phone number

SCA enrollment therefore impacts the user endpoints and user management flows.

​

SCA authentication

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

• Recipient creation, 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

SCA authentication therefore impacts the recipient creation endpoint, the transfer endpoint, and 4 endpoints for wallet access.

​

Taking action by proxy with user consent

Due to your platform’s activity and integration workflow, you may wish to take actions on behalf of users in certain circumstances. If the action is one that is subject to SCA, then it is possible if:

• The legal documentation (e.g. terms and conditions) between your platform and the user includes the actions that you take on their behalf by proxy
• Mangopay has the user’s consent to the proxy that allows your platform to act on the user’s behalf for the specific action – this is managed through the hosted SCA experience

Read more about proxy management →

​

Integration required for SCA

The following table lists the actions and endpoints on which SCA redirection is required (or may be required, because Mangopay may be able to exempt a given transfer or wallet access request). Additional integration is required if your platform is taking actions by proxy on behalf of the user (and sending the ScaContext value USER_NOT_PRESENT) – read more →

​

Enrollment and authentication

Action (and guide)	Endpoint
User creation (if OWNER)	POST Create a Natural User POST Create a Legal User
User categorization (from PAYER to OWNER)	POST Categorize a Natural User POST Categorize a Legal User
User modification if SCA contact details changed (re-enrollment)	PUT Update a Natural User PUT Update a Legal User
Recipient creation (if OWNER and RecipientScope is PAYOUT)	POST Create a Recipient
Transfer initiation to another OWNER (unless specific transfer is exempted by Mangopay as low-amount or low-risk) using ScaContext	POST Create a Transfer
Wallet access (unless SCA for wallet access was performed in the last 180 days) using ScaContext	GET View a Wallet GET List Wallets for a User GET List Transactions for a User GET List Transactions for a Wallet

​

Enrollment of legacy users

Additionally, you need to integrate the following endpoint to proactively enroll any legacy existing Owner users who have not enrolled in SCA:

• POST Enroll a User in SCA

​

Webhooks

Because SCA redirection is required on POST Create a Transfer, you must ensure your integration relies on the following webhook event types for the asynchronous outcome of SCA:

• TRANSFER_NORMAL_CREATED
• TRANSFER_NORMAL_FAILED
• TRANSFER_NORMAL_SUCCEEDED

To retry a failed transfer and retrieve a new SCA redirection link, call the POST Create a Transfer endpoint. There are also webhook event types that inform you about enrollment attempts (but not authentication):

• SCA_ENROLLMENT_SUCCEEDED
• SCA_ENROLLMENT_EXPIRED
• SCA_ENROLLMENT_FAILED

And there are two webhook event types relating to enrollment attempts specifically in the User endpoints:

• USER_ACCOUNT_VALIDATION_ASKED
• USER_ACCOUNT_ACTIVATED

​

Hosted webpage

Mangopay is introducing SCA across its API through a secure and hosted webpage. On relevant endpoints across Mangopay’s API, the base URL for a user’s session is provided in the response parameter PendingUserAction.RedirectUrl. You are able to define a specific page for the user to be returned to after the session. For the user, Mangopay’s SCA session provides a user-friendly experience that guides them efficiently through all the necessary steps relating to all required factors. Mangopay’s hosted SCA session handles both enrollment and authentication. Read how to redirect for an SCA session →

​

Factors

Mangopay’s hosted SCA session allows the user to both enroll in SCA and authenticate using the required factors. Read more →

Factor	Required	Type	Description
Trusted device using WebAuthn passkey	No	Possession (of device) and inherence (if biometrics) or knowledge (if password or passcode)	The individual uses the native authentication features (biometrics, password, passcode) of their device that they set up during enrollment.
Personal identification number (PIN)	Yes	Knowledge	The individual enters a 6-digit code they defined during enrollment.
Phone-based one-time passcode (OTP)	If passkey not used	Possession	The individual receives a 6-digit OTP via SMS to the phone number provided during enrollment.

​

Exemptions on actions

The SCA regulations allow Mangopay to apply an exemption to a given instance of an SCA-triggering action. The exemptions that Mangopay can apply depend on the action being authenticated. Enrollment cannot be exempted, because it is necessary to enable SCA to be performed. For Transfers and account access, your platform has a degree of visibility over the exemptions based on the response from the API. If the PendingUserAction.RedirectUrl was not returned on an action that is subject to SCA, then Mangopay was able to apply an exemption, and SCA redirection is not required for that instance of the action.

​

Exemptions available to Mangopay

Action	Exemptions applicable by Mangopay
User being assigned OWNER category (creation or categorization)	None, because this represents SCA enrollment
Change of SCA contact details	None, because this represents SCA re-enrollment
Recipient (bank/payment account) registration	None. Systematic SCA on Recipients enables your users to benefit from an SCA exemption when they request a payout, because the account can be considered a trusted beneficiary.
Transfer initiation between OWNER users	Two kinds of exemptions may be applied by Mangopay on Owner-initiated transfers to other Owners. Note that for transfers between wallets held by the same Owner, SCA does not apply. An Owner also can’t transfer to a Payer. Low-amount transfers Transactions under €30 may be exempted from SCA until they reach one of the following limits: More than 5 consecutive transactions More than €100 in cumulated transactions Low-risk transfers Transaction risk analysis (TRA) calculations, done by Mangopay, may be able to exempt SCA on transactions up to €500 (in the absence of detected risks). The regulations apply thresholds of transaction amounts based on Mangopay’s overall fraud rate for transfers and payouts. The data and calculations used will not be shared with platforms.
Account access (wallet, transaction history)	Accessing wallet balances and listing transactions may be exempted if the last SCA for either of these actions occurred less than 180 days ago. SCA performed for a different action not related to account access, such as registering a Recipient (bank/payment account) or initiating a transfer, cannot be used to exempt account access.

​

Notes on other actions

​

Payouts

While the payouts are in scope of SCA as per the regulations, Mangopay automatically applies the trusted beneficiary exemption because the Recipient registration was authenticated with SCA. This means that OWNER users will not be asked to perform SCA on payout requests.

​

KYC and UBO

Submitting KYC Documents and UBO Declarations for review does not require SCA.

​

FX conversions

Because FX conversions take place between two wallets held by the same user, conversions are not impacted by SCA.

​

Refunds

Refunds of all types are not impacted by SCA. Pay-in and transfer refunds continue to be possible for PAYER users. Furthermore, refunds that use payouts (by citing the reference of the initial transaction as the PAYIN_REFUND reason) continue to be possible for PAYER users, because a Recipient can be created for this purpose (see Recipient scopes - Pay-in).

​

Disputes

The dispute process is unaffected by Mangopay’s SCA features.

​

Pay-ins

In a pay-in context, a PAYER (or OWNER) is asked to authenticate the transaction by their issuing bank or PSP. This authentication may also be mandated by the same European regulations (PSD2). For example, 3DS on card transactions addresses the requirements of SCA. On pay-ins, Mangopay enables redirection for users to perform this authentication with third-parties, such as card networks, issuing banks, and payment method providers. In the API, this takes place via the SecureModeRedirectURL (e.g. direct and recurring card pay-ins, preauthorizations, etc.) or other RedirectURL (e.g. on APMs and web card pay-ins) that Mangopay returns in response to the pay-in request. However, in the pay-in scenario, the issuing bank or PSP of the user is in charge of applying SCA and allowing any exemptions. Mangopay’s introduction of SCA on OWNER users does not have any impact on pay-in authentication or your existing checkout or payment page integrations.

​

Connecting to the Mangopay Dashboard

Your platform’s team members use multi-factor authentication (MFA) to log in to the Mangopay Dashboard. This security feature is not changing and will remain in place, and it is entirely separate from the SCA requirements regarding end users of Mangopay’s payment and/or e-money services.

​

Using the Mangopay Dashboard

SCA is applicable to all the SCA-triggering actions that the OWNER user takes, whether via the API or via the Dashboard. For SCA-triggering actions taken via the Dashboard on behalf of end users, your platform needs to ensure that:

• The legal documentation (e.g. terms and conditions) between your platform and the user includes the proxy under which you take the action on their behalf
• Your platform collects and manages the user’s consent for the action

For more information, see managing proxy and user consent → The Dashboard will integrate the API-based SCA-features, but presently it has the legacy user endpoints integrated. Note that if you change a PAYER to OWNER via the Dashboard, that action uses the legacy PUT Update a User endpoint, and as such it will not trigger SCA, even if the PAYER was created using the new SCA-enabled endpoint. Such a user will still need to enroll as an existing user via the POST Enroll a User endpoint.

​

Platform user category

The UserCategory value PLATFORM indicates a specific user approved by Mangopay that represents the platform. Initially, SCA will not be applied to a User whose UserCategory is PLATFORM. SCA is applicable to actions taken by these users, however, and Mangopay is defining a suitable solution. This will involve an additional authentication factor (a mTLS certificate) to apply SCA to your platform’s interactions with Mangopay – read more about SCA on your platform →

​

Your platform’s MFA features

Your platform may already require users to complete multi-factor or two-factor authentication (MFA or 2FA) when they connect to your platform. Any existing MFA features your platform operates cannot be used to substitute or replace Mangopay’s independent SCA on OWNER users. The regulations require Mangopay Account holders to perform SCA with Mangopay directly.