> ## Documentation Index > Fetch the complete documentation index at: https://docs.mangopay.com/llms.txt > Use this file to discover all available pages before exploring further. # Introduction to SCA > Learn about Mangopay's SCA features applicable to Owner users 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)](/guides/glossary#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](#pay-ins) about SCA with their issuers on pay-ins. For information and users whose `UserCategory` is `PLATFORM`, [see below](#platform-user-category). ## 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. **Note – SCA cannot be delayed** On all the actions above, SCA is triggered immediately when the API request is made. The API response contains the URL of a secure [hosted SCA webpage](#hosted-webpage) to which your platform needs to redirect the individual. The SCA session (the `RedirectUrl` in the API response) is valid for **10 minutes** from when it is generated. The `OWNER` user must complete all the necessary steps for enrollment or authentication before the session expires. It is not possible to initiate an action and then ask the user to complete the SCA session later. ### 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](/guides/sca/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](/guides/sca/session) using the `PendingUserAction.RedirectUrl` returned so that the user can complete the SCA session (unless Mangopay applied an [exemption](/#exemptions-available-to-mangopay) 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](/guides/sca/proxy-management#integration-timeline) **→** #### 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. **Caution – Default value changing Dec 15, 2025** On **Transfers** and **wallet access**, the default value for `ScaContext` will change to `USER_PRESENT` on **Dec 15, 2025** (for transfers between `OWNER` users and their wallets). This means that [SCA redirection](/guides/sca/session) will be required if the `PendingUserAction.RedirectUrl` is returned. In Sandbox, the default value is changing on **Dec 1, 2025**. #### Enrollment and authentication
Action (and guide) Endpoint
[User creation](/guides/sca/users#register-an-owner-for-the-first-time) (if `OWNER`) * [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)
[User categorization](/guides/sca/users#transition-a-payer-to-owner) (from `PAYER` to `OWNER`) * [POST Categorize a Natural User](/api-reference/users/categorize-natural-user) * [POST Categorize a Legal User](/api-reference/users/categorize-legal-user)
[User modification](/guides/sca/users#re-enroll-an-enrolled-owner) if SCA contact details changed (re-enrollment) * [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)
[Recipient creation](/guides/sca/recipients) (if `OWNER` and `RecipientScope` is `PAYOUT`) * [POST Create a Recipient](/api-reference/recipients/create-recipient)
[Transfer initiation](/guides/sca/transfers) to another `OWNER` (unless specific transfer is exempted by Mangopay as low-amount or low-risk) using `ScaContext` * [POST Create a Transfer](/api-reference/recipients/create-transfer)
[Wallet access](/guides/sca/wallets) (unless SCA for wallet access was performed in the last 180 days) using `ScaContext` * [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)
**Caution – ScaContext is mandatory in all cases** For all platforms, the `ScaContext` parameter on transfers and wallet access is mandatory in all cases where the User is an `OWNER`. Its values in all cases mean: * `USER_PRESENT` – The user is taking the SCA-triggering action. The platform must [redirect the user](/guides/sca/session) using the `PendingUserAction.RedirectUrl` returned so that the user can complete the SCA session (unless Mangopay applied an exemption, so no redirection link was returned). * `USER_NOT_PRESENT` – The platform is taking the action under [proxy](/guides/sca/proxy-management) from the user and the user has previously given consent to Mangopay (via the SCA hosted experience) to allow the action. **Note – Bypass SCA in Sandbox testing** To facilitate testing in Sandbox, you can bypass SCA on all SCA-triggering actions – Owner registration, recipient creation, transfer, and wallet access. To do so, include the word `accept` in the Natural User's `Email` or the Legal User's `LegalRepresentative.Email` – for example `accept@example.com` or `john.doe+accept@example.com`. #### Enrollment of legacy users Additionally, you need to integrate the following endpoint to proactively [enroll any legacy existing Owner users](/guides/sca/users#enroll-an-existing-owner) who have not enrolled in SCA: * [POST Enroll a User in SCA](/api-reference/users/enroll-user) #### Webhooks Because SCA redirection is required on [POST Create a Transfer](/api-reference/transfers/create-transfer), you must ensure your integration relies on the following [webhook event types](/webhooks/event-types#transfers) 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](/api-reference/transfers/create-transfer) endpoint. There are also [webhook event types](/webhooks/event-types#mangopay-sca-enrollment) 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](/webhooks/event-types#user-account) relating to enrollment attempts specifically in the User endpoints: * `USER_ACCOUNT_VALIDATION_ASKED` * `USER_ACCOUNT_ACTIVATED` {/* ### Deadline for integration **Deadline for integration** Implementation of Mangopay's SCA features for all actions impacted by SCA is mandatory for all platforms. Your platform should start integrating features as soon as they become available. **Deadline for platforms to integrate:** July 1, 2025 If you have any concerns about integration timelines, please contact our teams via the Dashboard. */} **Best practice – Start testing in Postman** The Mangopay API Postman collection contains dedicated folders for SCA-enabled User endpoints, Recipient endpoints, and simulating SCA on transfers and wallet access. See the [Postman](/postman) guide for details on how to fork the collection and set up your environment with your `ClientId` and API key. ## 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. **Note – Add your return URL before redirection** You must add your `returnUrl` before you redirect the user on the `RedirectUrl` value, otherwise the hosted web page cannot return them upon completion. [Read how to redirect for an SCA session](/guides/sca/session) **→** ## Factors Mangopay's hosted SCA session allows the user to both enroll in SCA and authenticate using the required factors. [Read more](/guides/sca/factors) **→**
Factor Required Type Description
Trusted device using WebAuthn [passkey](/guides/sca/factors#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)](/guides/sca/factors#pin) Yes Knowledge The individual enters a 6-digit code they defined during enrollment.
Phone-based [one-time passcode (OTP)](/guides/sca/factors#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. **Note – Exemptions applied by Mangopay** As a regulated PSP, Mangopay applies and requests exemptions on behalf of platforms. The exemptions that Mangopay may apply are detailed below. Platforms cannot request specific exemptions in a given situation. Platforms also cannot be exempted from integration of SCA – it is mandatory requirement. 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 EUR may be exempted from SCA until they reach one of the following limits: * More than 5 consecutive transactions * More than 100 EUR 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 EUR (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](/guides/payouts/integration#refunds-using-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](/guides/sca/recipients#recipient-scopes)). #### 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](#actions-requiring-sca) 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](/guides/sca/proxy-management) **→** 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](/api-reference/users/enroll-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](/guides/sca/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.