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).

SCA redirection on enrollment and authentication actions is orchestrated in the API by the ScaContext parameter, which has the following values:

• USER_PRESENT – The user is taking the SCA-triggering action. The platform must redirect the user using the PendingUserAction.RedirectUrl returned so that the user can complete the SCA session (unless Mangopay applied an exemption on the given instance of an action, so no redirection link was returned).
• USER_NOT_PRESENT – The platform is taking the action under proxy from the user and the user has previously given consent to Mangopay (via the SCA hosted experience) to allow the action. If the user has not given (or has revoked) their consent, then USER_NOT_PRESENT returns a 403 error.

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 →

SCA enforcement

SCA redirection logic needs to be implemented on the actions listed below.

To roll out this change, Mangopay delivered:

• New endpoints (with /sca/ in the URL path) for User creation, categorization, and modification
• New endpoint to create Recipients (replacing legacy Bank Accounts)
• Changes to the existing Transfer creation and 4 relevant wallet access endpoints

On Users and Recipients, the default value for ScaContext was introduced as USER_PRESENT, as the endpoints could be newly integrated.

On Transfers and wallet access, the default value for ScaContext was introduced as USER_NOT_PRESENT as a temporary measure to allow adoption without breaking existing flows.

Enrollment and authentication

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 →

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

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.