Authentication factors

Mangopay is delivering SCA via a unique session on a hosted webpage. The URL for the session is returned on relevant API calls, and your platform needs to redirect the user to complete the session – see SCA session for details on how to do this.

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.

​

Localization

The hosted SCA page is automatically set to the language of the browser. The following languages are supported: Dutch, English, French, German, Italian, Portuguese, Spanish.

If the browser is in a language not listed above, the session stays in English by default.

​

Welcome screen

On the RedirectUrl, the user first sees a Mangopay-branded welcome screen explaining the steps that are required from them.

​

Welcome screen on enrollment

Below is an example of the SCA welcome screen for an Owner user enrolling at user creation:

​

Welcome screen on authentication

Below is an example of the SCA welcome screen for a on Owner authenticating a transfer request above 30 EUR:

The wording is adapted for both enrollment and authentication depending on the scenario. The platform trading name is always shown, along with:

• For a transfer request, the transfer currency and amount
• For recipient bank account registration, the IBAN or local account number
• For wallet access, a mention of access to personal account information

See what conditions trigger SCA in Sandbox for more support with testing each scenario: users, recipients, transfers, and wallet access.

​

Factors presented

Mangopay provides the following authentication factors.

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.

​

Logic governing optional trusted devices

Defining a trusted device using a WebAuthn passkey is optional.

If the user chooses to enroll a trusted device, then only the PIN is enrolled as the second factor.

If the user chooses to authenticate using a trusted device, then the passkey alone satisfies SCA because it is a combination of two factors.

If at either point the uses skips the use of a trusted device, then the PIN and OTP are both used. Skipping the passkey is possible during authentication even if a device is already enrolled because the user may not be using their trusted device.

​

Passkey

The passkey factor relies on the Web Authentication, or WebAuthn, standard to create a set of two passkeys (or credentials):

• A public key that is not secret and is stored on the Mangopay server
• A private key that is secret and is stored on the user’s device

The private key is accessed using the device’s authentication features: for example, a password or fingerprint on a laptop; or a passcode, fingerprint, or face on a smartphone.

Because WebAuthn doesn’t rely on a new password, it is more resistant to phishing and data breaches. It has wide adoption on web browsers and mobile devices.

For mobile app integrations, passkeys are not supported if the RedirectUrl is opened in a webview. The factor must be integrated natively. See the dedicated guides for details on how to do this:

​

Passkey device enrollment

To enroll, the user:

1. Chooses to enroll their device as a trusted device
2. Selects where to store the passkey from the options proposed by their device
3. Authenticates using their device authentication feature (biometrics, password, passcode)

Below is an example of the enrollment process using Chrome on MacOS, a passkey stored in a Google Chrome profile, and the laptop password.

​

Passkey device authentication

During authentication:

1. Indicates that they are using their trusted device
2. Selects the passkey to use
3. Authenticates using their device authentication feature (biometrics, password, passcode)

Below is an example of the authentication process using Chrome on MacOS, a passkey stored in a Google Chrome profile, and the laptop password.

​

PIN

The PIN factor relies on a 6-digit code defined and memorized by the individual, which they enter during the session.

​

PIN enrollment

To enroll, the individual:

1. Defines and confirms a 6-digit PIN
2. Enters their PIN defined previously

​

PIN authentication

To authenticate, the individual:

1. Enters their PIN defined previously

​

OTP

The OTP factor relies on a temporary 6-digit code sent to the individual’s phone, which they can enter during the session.

​

OTP enrollment

To enroll, the individual:

1. Enters their mobile phone number (or confirms the pre-populated number, if PhoneNumber was present in the API call to create or update the user)
2. Enters the 6-digit code received by SMS

​

OTP authentication

To authenticate, the individual:

1. Enters the 6-digit code received by SMS

​

Test data

In Sandbox, you can use the phone number 0611111111 and FR (+33611111111) with the passcode 702100 to simulate a successful flow. You can also send this data in the PhoneNumber (or LegalRepresentative.PhoneNumber) to pre-populate the field.

You can also test by using a real phone number to receive the SMS OTP.

​

Handling phone number data

Mangopay’s SCA session allows the individual to provide their phone number directly to Mangopay. This data is not shared with your platform for privacy reasons. The same phone number can be used with more than one user account.

Your platform can send the user’s phone number to Mangopay via the API – in the PhoneNumber parameter of the Natural User or the LegalRepresentative.PhoneNumber of the Legal User.

If the phone number data is present in the user object, then the field is pre-populated for the user to confirm or modify.