> ## 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. # SCA on users > Read about how SCA impacts user endpoints ## Introduction When a Mangopay Account is created, the account holder must enroll in SCA. A Mangopay account is created when a Natural or Legal user is assigned the `UserCategory` of `OWNER`, because these users accept and are bound by Mangopay's T\&Cs and are being provided with Mangopay payment and/or e-money services. Mangopay Account creation is not in itself an action subject to SCA, but enrollment in SCA must happen at the same time. Therefore, the user management endpoints return an SCA redirection link when the `OWNER` value is assigned. The unique SCA session link is returned in the `PendingUserAction.RedirectUrl`. Your platform needs to use the `RedirectUrl` to redirect the individual to Mangopay's hosted-webpage so they can enroll. See [SCA session](/guides/sca/session) for more details on how to do this. The SCA session always requires the email address of the individual performing SCA, because the email is used to build anonymized behavioral biometrics data. The phone number can be entered by the individual during the SCA session for the OTP SMS factor – you don't have to send it via the API. See the SCA factors guide for more details on [how the email is used](/guides/sca/factors#email-confirmation-behavioral-biometrics) and on [managing phone numbers](/guides/sca/factors#handling-phone-number-data). ## Integration In addition to the introductory notes presented here for natural and legal users, see below for details on [Sandbox testing](#testing) and the different scenarios for [enrollment in the user lifecyle](#enrollment-in-the-user-lifecyle). ### Natural user integration For **Natural users**, the SCA session uses: * The mandatory `Email` property * The optional `PhoneNumber` and `PhoneNumberCountry` if provided ### Legal user integration SCA applies to all types of legal users: Soletrader, Business, Organization, and Partnership. For SCA on Legal Users: * A single individual can complete SCA for a Legal User * The individual’s email and phone number must be registered as the Legal User’s * `LegalRepresentative.Email` * `LegalRepresentative.PhoneNumber` * `LegalRepresentative.PhoneNumberCountry` The declared individual will be required to enroll in SCA and authenticate SCA-triggering actions. #### How to prepare your integration for SCA Legal Users: **1. Check the contact details of the individual performing SCA and update if needed** You can retrieve the data points above via the [GET View a User (SCA)](/api-reference/users/view-user-sca) endpoint, using the `UserId` as a path parameter. To update the email and phone number, call [PUT Update a Legal User (SCA)](/api-reference/users/update-legal-user-sca), sending only the new data values and the other required fields. ```json REST theme={null} { "UserCategory": "OWNER", "TermsAndConditionsAccepted": true, "LegalRepresentative": { "Email": "alex.smith@example.com", "PhoneNumber": "0611111111", "PhoneNumberCountry": "FR" } } ``` **Caution – Including other data may trigger KYC/B downgrade** Make sure your API call doesn't include any other sub-properties of the `LegalRepresentative` object, otherwise you may inadvertently trigger a KYC/B downgrade. **2. Ensure you have the SCA redirection logic in place for all Legal User types** For legal users, you need to redirect the user to the hosted SCA session regardless of their `LegalPersonType`. SCA redirection is required to complete SCA-triggering actions if the `PendingUserAction.RedirectUrl` is returned by the API. See [integration required for SCA](/guides/sca#integration-required-for-sca) for the full list of scenarios and endpoints where you need to implement SCA redirection logic. **3. Enroll the User proactively (recommended)** Your platform should enroll all existing `OWNER` users proactively using [POST Enroll a User in SCA](/api-reference/users/enroll-user). As a temporary measure to encourage adoption, legacy users can also enroll in SCA on any of SCA sessions returned by the API. ### Existing user integration Existing users will not be immediately restricted by the introduction of SCA ([see below](#restrictions-on-existing-users)). For existing users, both Natural and Legal (all types), SCA redirection will be triggered in the following scenarios: * For existing `PAYER` users, when you change their category to `OWNER` using [PUT Categorize a Natural User](/api-reference/users/categorize-natural-user) or [PUT Categorize a Legal User](/api-reference/users/categorize-legal-user) * For existing `OWNER` users, when you: * Enroll them proactively using [POST Enroll a User](/api-reference/users/enroll-user) * Register a payout [Recipient](/guides/sca/recipients) (bank/payment account) for them * Request a [user-initiated transfer](/guides/sca/transfers) for them to another `OWNER` * Request to access their [wallet balance or transaction history](/guides/sca/wallets) Mangopay's SCA session allows the user to enroll or authenticate as required. We recommend inviting your active Owner users to enroll when they interact with your platform, which you can do using the [POST Enroll a User](/api-reference/users/enroll-user) endpoint. **Caution – Legal representative's email required** For `OWNER` users, the `LegalRepresentative.Email` address is required. SCA uses this email address to build a [behavioral biometrics profile](/guides/sca/factors#email-confirmation-behavioral-biometrics) and as a backup communication channel. Prior to SCA, it was possible to create a Legal `OWNER` without the `LegalRepresentativeEmail`, so this data may be missing. Calling the [POST Enroll a User in SCA](/api-reference/users/enroll-user) endpoint without this data will return an error. 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. For OWNER accounts that are not longer in use, your platform can request their closure using the dedicated endpoints: * [DELETE Close a Natural User](/api-reference/users/close-natural-user) * [DELETE Close a Legal User](/api-reference/users/close-legal-user) ### Integration action required on Users **Action required:** For **new** Natural and Legal Users (of all types): * Integrate the SCA-enabled endpoints for user creation. [Read how](/guides/sca/users#register-an-owner-for-the-first-time) **→** * Integrate the SCA-enabled endpoints for changing a `PAYER` to an `OWNER`. [Read how](/guides/sca/users#transition-a-payer-to-owner) **→** * Integrate the SCA-enabled endpoints for re-enrollment of enrolled users. [Read how](/guides/sca/users#re-enroll-an-enrolled-owner) **→** The SCA-enabled endpoints must be integrated for `PAYER` users too, regardless of whether they are likely to be come `OWNER`. For **existing** users (Natural and Legal Soletrader): * Integrate SCA enrollment of existing `OWNER` users at an appropriate moment in your user journey using the dedicated endpoint. [Read how](/guides/sca/users#enroll-an-existing-owner) **→** **Possible SCA exemptions on Users:** * None, because these actions are enrollment or re-enrollment. ## User status The SCA-enabled user endpoints introduced a new possible value for the `UserStatus` response parameter. For users created prior to or without SCA, `UserStatus` has two possible values, which were the same for `PAYER` and `OWNER`.
`UserStatus` value Without SCA and for all `PAYER`
`ACTIVE` (default) The user is active and can access Mangopay features.
`CLOSED` The user is permanently deactivated.
For the `OWNER` category with SCA, the property can have a new value, `PENDING_USER_ACTION`, which is assigned by default. Once the user has completed SCA, their status changes to `ACTIVE`.
`UserStatus` value `OWNER` with SCA
`PENDING_USER_ACTION` (default) The user must successfully enroll in SCA before for their account to become `ACTIVE`.
`ACTIVE` The user account is active and can access Mangopay features, such as wallets and KYC/B verification. Note that `ACTIVE` does not mean that the user is SCA-enrolled. This is because pre-SCA existing users have the `ACTIVE` value, and it is possible to change the `UserCategory` on the legacy endpoint (see caution below).
`CLOSED` The user is permanently deactivated.
### Pending user action The `PENDING_USER_ACTION` status value indicates that the user needs enroll (or re-enroll) in SCA. #### Triggers The user's `UserStatus` becomes `PENDING_USER_ACTION` after the following events: * Creation using the SCA-enabled POST endpoints 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) * Categorization as `OWNER` using the SCA-enabled endpoints: * [PUT Categorize a Natural User](/api-reference/users/categorize-natural-user) * [PUT Categorize a Legal User](/api-reference/users/categorize-legal-user) * If already enrolled in SCA, modification `Email` (`LegalRepresentative.Email`) or `PhoneNumber` (`LegalRepresentative.PhoneNumber`) via the SCA-enabled PUT endpoints: * [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) Set up a [webhook notification](/webhooks) for the [event type](/webhooks/event-types) `USER_ACCOUNT_VALIDATION_ASKED` to be notified when the user's `UserStatus` changes to `PENDING_USER_ACTION`. The `USER_ACCOUNT_ACTIVATED` event type sends a notification when the `UserStatus` changes from `PENDING_USER_ACTION` to `ACTIVE`. **Note – POST Enroll a User endpoint doesn't change UserStatus** A call to the dedicated enrollment endpoint ([POST Enroll a User in SCA](/api-reference/users/enroll-user)) does **not** change the user's status to `PENDING_USER_ACTION` (it stays as `ACTIVE`), and no `USER_ACCOUNT_VALIDATION_ASKED` webhook notification is sent. This ensures that legacy users do not become blocked if they are unable to complete SCA successfully. #### Refused actions If your user remains in a `PENDING_USER_ACTION` status, then you can use [POST Enroll a User in SCA](/api-reference/users/enroll-user) to retrieve a new SCA session for them to enroll. **Note – PENDING\_USER\_ACTION users no longer blocked** Prior to mid-September 2025, the `PENDING_USER_ACTION` value for `UserStatus` prevented the user from accessing the endpoints listed below. Since mid-September 2025, the `PENDING_USER_ACTION` status does not block the user but only indicates that they need to enroll in SCA. For `PENDING_USER_ACTION` users, only the SCA-triggering actions are blocked until the user successfully enrolls in SCA. Prior to mid-September 2025, when the user's `UserStatus` was `PENDING_USER_ACTION`, they were unable to take the following actions: * Request a payout using [POST Create a Payout](/api-reference/payouts/create-payout) * Register a recipient using [POST Create a Recipient](/api-reference/recipients/create-recipient) * Register a bank account using any of the [POST Create a Bank Account](/api-reference/bank-accounts/bank-account-object) endpoints * Request a transfer debiting their wallet, using [POST Create a Transfer](/api-reference/transfers/create-transfer) if they are referenced as the `AuthorId` or the owner of the `DebitedWalletId` * View their wallet balance using [GET View a Wallet](/api-reference/wallets/view-wallet) * List their wallets using [GET List Wallets for a User](/api-reference/wallets/list-wallets-user) * List transactions for a wallet they own using [GET List Transactions for a Wallet](/api-reference/transactions/list-transactions-wallet) * List their transactions using [GET List Transactions for a User](/api-reference/transactions/list-transactions-user) Attempts to perform the actions above returned an error. In some cases this was indicated by a 400 response: ```json 400 theme={null} { "Message": "This endpoint is not allowed for User with your current status", "Type": "not_allowed_for_pending_user_action_status", "Id": "57f871d3-f467-4360-ae74-6af4dac4fb02#1743583911", "Date": 1743583912, "errors": null } ``` On transfers, such a request failed immediately with the dedicated `ResultCode`: * [002704](/errors/codes/002704) – Users in PENDING\_USER\_ACTION status cannot create transfers ### Restrictions on existing users **Note – Existing users not restricted** Initially, existing users will not be 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](/api-reference/users/enroll-user) and the SCA session is not successful. This means that currently there is no way to distinguish an SCA-enrolled user from one that is not – both have `UserStatus` of `ACTIVE`. 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. In future, Mangopay may be required by regulators to start introducing consequences on users if they haven't enrolled in SCA, but this will be done with sufficient notice to platforms. These consequences may include removing certain permissions, blocking the account, reverting the category to Payer, or closing the account. ## Webhooks There are two new event types for which you can create [webhook notifications](/webhooks). In both cases the `RessourceId` of the notification received is the `UserId`. * `USER_ACCOUNT_VALIDATION_ASKED` – The Owner user has triggered SCA enrollment, meaning that their `UserStatus` has changed to `PENDING_USER_ACTION`. * `USER_ACCOUNT_ACTIVATED` – The Owner user has been successfully enrolled in SCA and their `UserStatus` has changed from `PENDING_USER_ACTION` to `ACTIVE`. **Note – Webhooks not triggered for non-SCA Owners** The user account webhooks are not triggered for: * Payers * Owners if they are created or categorized with the non-SCA endpoints ## Enrollment in the user lifecycle The following scenarios describe how you can enroll your users in SCA to create their Owner user account. For an overview, see the [diagram below](#user-lifecycle-diagram%3A-categories). In each case, the API call triggers SCA and returns the `PendingUserAction.RedirectUrl` redirection link. And in each case, the way you need to redirect the user and handle the outcome is the same. For more detailed guidance on this redirection process, [SCA session](/guides/sca/session). ### Testing #### SCA triggers in Sandbox In Sandbox, SCA is triggered on the SCA-enabled creation (POST) and categorization (PUT) endpoints when all of the following are true: * `UserCategory` is `OWNER` * The user's type is Natural or Legal (all `LegalPersonType` – `BUSINESS`, `SOLETRADER`, `ORGANIZATION`, or `PARTNERSHIP`) In Sandbox, SCA is not triggered if any of the following are true: * `UserCategory` is `PAYER` Notes: * [POST Enroll a User](/api-reference/users/enroll-user) returns `PendingUserAction.RedirectUrl` regardless of the user type * The PUT endpoints only trigger SCA redirection if `PhoneNumber`, `PhoneNumberCountry`, or `Email` are changed #### OTP test number and code To test the OTP factor in Sandbox, you can use the `PhoneNumber` `+33611111111` (or `0611111111` and `FR`) and the passcode **702100** to simulate a successful flow. You can also use a real phone number to receive the SMS OTP. #### Postman The Mangopay API Postman collection contains a dedicated folder for the SCA-enabled User endpoints ready for you to test the solution. See the [Postman](/postman) guide for details on how to fork the collection and set up your environment with your `ClientId` and API key. #### Bypass SCA in Sandbox In Sandbox, you can bypass SCA by including the word `accept` in the [Natural User's](/api-reference/users/natural-user-object-sca) `Email` or the [Legal User's](/api-reference/users/legal-user-object-sca) `LegalRepresentative.Email` – for example `accept@example.com` or `john.doe+accept@example.com`. If the user has `accept` in their email, then the API does not apply SCA during [enrollment in the User endpoints](/guides/sca/users) or any of the SCA-triggering actions – ([recipient creation](/guides/sca/recipients), [transfers](/guides/sca/transfers), and [wallet access](/guides/sca/wallets)). The API proceeds with the requested action and doesn't return the `PendingUserAction.RedirectUrl` SCA redirection link. ### Register an Owner for the first time The following flow should be used to create new Owners and enroll them in SCA at the same time. Any users Owner created on the non-SCA endpoints will need to be enrolled separately (in [the flow described below](#enroll-an-existing-owner)). Call the [POST Create a Natural User (SCA)](/api-reference/users/create-natural-user-sca) endpoint to register an Owner and enroll them in SCA: * Set `UserCategory` to `OWNER` * Set `TermsAndConditionsAccepted` to `true` (ensuring you have obtained the user's acceptance of Mangopay's T\&Cs) * Provide the required data for Owners - `FirstName` (for KYC purposes, checked against the ID proof document) - `LastName` (for KYC) - `Email` (for SCA purposes, used during the SCA session) - `Birthday` (for KYC) - `Nationality` (for KYC) - `CountryOfResidence` (for KYC) If you provide the `PhoneNumber`, it will be pre-populated in the hosted SCA experience for them to confirm or change; otherwise, they will be asked to provide it. Call the [POST Create a Legal User (SCA)](/api-reference/users/create-legal-user-sca) endpoint to register an Owner and enroll them in SCA: * Set `UserCategory` to `OWNER` * Set `TermsAndConditionsAccepted` to `true` (ensuring you have obtained the user's acceptance of Mangopay's T\&Cs) * Set the `LegalPersonType` as `SOLETRADER` to simulate the SCA redirection (see [SCA triggers in Sandbox](/#sca-triggers-in-sandbox)) * Provide the required data for Owners - `Name` (registered legal name) - `Email` (for the registered entity) - `HeadquartersAddress` (registered address) - `CompanyNumber` (required for Business, relevant for others if available) For the individual (in the `LegalRepresentative` object): * `FirstName` (for KYC/B purposes, checked against the ID proof document) * `LastName` (for KYC/B) * `Email` (for SCA purposes, used during the SCA session) * `Birthday` (for KYC/B) * `Nationality` (for KYC/B) * `CountryOfResidence` (for KYC/B) If you provide the `LegalRepresentative.PhoneNumber`, it will be pre-populated in the hosted SCA experience for them to confirm or change; otherwise, they will be asked to provide it. In the API response: * `UserCategory` is `OWNER` * `UserStatus` is `PENDING_USER_ACTION` * `PendingUserAction.RedirectUrl` contains the unique URL for the user's SCA session The `PENDING_USER_ACTION` status triggers a [webhook notification](/webhooks) for the `USER_ACCOUNT_VALIDATION_ASKED` event type – set up this [Hook](/api-reference/webhooks/create-hook) to be notified. Define a URL to which the user will be redirected after the SCA session. Encode the URL and append it to the `RedirectUrl` value as the `returnUrl` query parameter (for details see [How to redirect a user for an SCA session (Step 2 onwards)](/guides/sca/session#2-retrieve-the-sca-redirect-url)). Then, redirect the user. After the SCA session, when the user is returned on your `returnUrl`, check the `controlStatus` query parameter attached by Mangopay (as described in [Step 5 and 6](/guides/sca/session#8-receive-the-user-on-return)). The Owner user is successfully SCA enrolled and their account created when the `UserStatus` changes from `PENDING_USER_ACTION` to `ACTIVE`. Set up a [webhook notification](/webhooks) for the `USER_ACCOUNT_ACTIVATED` event type to be notified of this. ### Transition a Payer to Owner **Note – Flow for all existing Payer users** You can use this flow to transition users Payer created before the introduction of SCA as well as those created on the new endpoint. Call the [PUT Categorize a Natural User (SCA)](/api-reference/users/categorize-natural-user) endpoint to transition an existing Payer: * Set `UserCategory` to `OWNER` * Set `TermsAndConditionsAccepted` to `true` (ensuring you have obtained the user's acceptance of Mangopay's T\&Cs) * Provide the required data for Owners - `FirstName` (for KYC purposes, checked against the ID proof document) - `LastName` (for KYC) - `Email` (for SCA purposes, used during the SCA session) - `Birthday` (for KYC) - `Nationality` (for KYC) - `CountryOfResidence` (for KYC) If you provide the `PhoneNumber`, it will be pre-populated in the hosted SCA experience for them to confirm or change; otherwise, they will be asked to provide it. Call the [POST Create a Legal User (SCA)](/api-reference/users/create-legal-user-sca) endpoint to register an Owner and enroll them in SCA: * Set `UserCategory` to `OWNER` * Set `TermsAndConditionsAccepted` to `true` (ensuring you have obtained the user's acceptance of Mangopay's T\&Cs) * Set the `LegalPersonType` as `SOLETRADER` to simulate the SCA redirection (see [SCA triggers in Sandbox](/#sca-triggers-in-sandbox)) * Provide the required data for Owners - `Name` (registered legal name) - `Email` (for the registered entity) - `HeadquartersAddress` (registered address) - `CompanyNumber` (required for Business, relevant for others if available) For the individual (in the `LegalRepresentative` object): * `FirstName` (for KYC/B purposes, checked against the ID proof document) * `LastName` (for KYC/B) * `Email` (for SCA purposes, used during the SCA session) * `Birthday` (for KYC/B) * `Nationality` (for KYC/B) * `CountryOfResidence` (for KYC/B) If you provide the `LegalRepresentative.PhoneNumber`, it will be pre-populated in the hosted SCA experience for them to confirm or change; otherwise, they will be asked to provide it. In the API response: * `UserCategory` is `OWNER` * `UserStatus` is `PENDING_USER_ACTION` * `PendingUserAction.RedirectUrl` contains the unique URL for the user's SCA session The `PENDING_USER_ACTION` status triggers a [webhook notification](/webhooks) for the `USER_ACCOUNT_VALIDATION_ASKED` event type – set up this [Hook](/api-reference/webhooks/create-hook) to be notified. Define a URL to which the user will be redirected after the SCA session. Encode the URL and append it to the `RedirectUrl` value as the `returnUrl` query parameter (for details see [How to redirect a user for an SCA session (Step 2 onwards)](/guides/sca/session#2-retrieve-the-sca-redirect-url)). Then, redirect the user. After the SCA session, when the user is returned on your `returnUrl`, check the `controlStatus` query parameter attached by Mangopay (as described in [Step 5 and 6](/guides/sca/session#8-receive-the-user-on-return)). The Owner user is successfully SCA enrolled and their account created when the `UserStatus` changes from `PENDING_USER_ACTION` to `ACTIVE`. Set up a [webhook notification](/webhooks) for the `USER_ACCOUNT_ACTIVATED` event type to be notified of this. ### Enroll an existing Owner **Note – Flow for existing Owner users** You can use this flow to transition of Owner users created before the introduction of SCA, meaning any Owner user: * Created on the non-SCA endpoint ([POST Create a Natural User](/api-reference/users/create-natural-user) or [POST Create a Legal User](/api-reference/users/create-legal-user)) * Categorized on the legacy **PUT Update a Natural/Legal User** endpoints (including via the Dashboard) Read more about integrating [SCA for existing users](#existing-user-integration). Call the [POST Enroll a User in SCA](/api-reference/users/enroll-user) endpoint to obtain an SCA session link for the user to enroll in SCA. If the `PhoneNumber` (Natural Users) or `LegalRepresentative.PhoneNumber` (Legal Users) is already present in the user object, it will be pre-populated in the hosted SCA experience for them to confirm or change; otherwise, they will be asked to provide it. On the enrollment endpoint, the API returns only the `PendingUserAction.RedirectUrl` property containing the unique URL for the user's SCA session. The user's `UserStatus` still changes to `PENDING_USER_ACTION`, which triggers the a `USER_ACCOUNT_VALIDATION_ASKED` [webhook](/webhooks). Define a URL to which the user will be redirected after the SCA session. Encode the URL and append it to the `RedirectUrl` value as the `returnUrl` query parameter (for details see [How to redirect a user for an SCA session (Step 2 onwards)](/guides/sca/session#2-retrieve-the-sca-redirect-url)). Then, redirect the user. After the SCA session, when the user is returned on your `returnUrl`, check the `controlStatus` query parameter attached by Mangopay (as described in [Step 5 and 6](/guides/sca/session#8-receive-the-user-on-return)). The Owner user is successfully SCA enrolled and their account created when the `UserStatus` changes from `PENDING_USER_ACTION` to `ACTIVE`. Set up a [webhook notification](/webhooks) for the `USER_ACCOUNT_ACTIVATED` event type to be notified of this. ### Re-enroll an enrolled Owner Re-enrollment is required when the `PhoneNumber`, `PhoneNumberCountry`, or `Email` user properties are modified. Call the [PUT Update a Natural User (SCA)](/api-reference/users/update-natural-user-sca) endpoint setting the required parameters: * `UserCategory` to `OWNER` * `TermsAndConditionsAccepted` to `true` If you modify the `PhoneNumber` and/or `PhoneNumberCountry`, then the SCA session pre-populates the phone number value for the user to confirm and enroll. If you modify only the `Email`, then the new email is confirmed using the `PhoneNumber` which was previously enrolled. In this case, the user is not given the opportunity to modify their phone number during the session. **Note:** In Sandbox, the [default behavior](#sca-triggers-in-sandbox) is that SCA redirection is only triggered if `LegalPersonType` is `SOLETRADER`. Call the [PUT Update a Legal User (SCA)](/api-reference/users/update-legal-user-sca) endpoint setting the required parameters: * `UserCategory` to `OWNER` * `TermsAndConditionsAccepted` to `true` If you modify the `LegalRepresentative.PhoneNumber` and/or `LegalRepresentative.PhoneNumberCountry`, then the SCA session pre-populates the phone number value for the user to confirm and enroll. If you modify only the `LegalRepresentative.Email`, then the new email is confirmed using the `LegalRepresentative.PhoneNumber` which was previously enrolled. In this case, the user is not given the opportunity to modify their phone number during the session. In the API response: * `UserCategory` is `OWNER` * `UserStatus` is `PENDING_USER_ACTION` * `PendingUserAction.RedirectUrl` contains the unique URL for the user's SCA session The `PENDING_USER_ACTION` status triggers a [webhook notification](/webhooks) for the `USER_ACCOUNT_VALIDATION_ASKED` event type – set up this [Hook](/api-reference/webhooks/create-hook) to be notified. **Note – PhoneNumber entered during SCA session not updated in API** The phone number provided during the SCA session is not updated retroactively in the API user object. This also applies if the `PhoneNumber` is already present and the user changes it during the SCA session. Any PUT call that changes the `PhoneNumber` value triggers SCA, even if the user just completed SCA. Define a URL to which the user will be redirected after the SCA session. Encode the URL and append it to the `RedirectUrl` value as the `returnUrl` query parameter (for details see [How to redirect a user for an SCA session (Step 2 onwards)](/guides/sca/session#2-retrieve-the-sca-redirect-url)). Then, redirect the user. After the SCA session, when the user is returned on your `returnUrl`, check the `controlStatus` query parameter attached by Mangopay (as described in [Step 5 and 6](/guides/sca/session#8-receive-the-user-on-return)). The Owner user is successfully SCA enrolled and their account created when the `UserStatus` changes from `PENDING_USER_ACTION` to `ACTIVE`. Set up a [webhook notification](/webhooks) for the `USER_ACCOUNT_ACTIVATED` event type to be notified of this. ## Integrate new user endpoints for Payers SCA is not applicable to `PAYER` users. However, the SCA endpoints must be integrated to register and update `PAYER` users: * [POST Create a Natural User (SCA)](/api-reference/users/create-natural-user-sca) * [PUT Update a Natural User (SCA)](/api-reference/users/update-natural-user-sca) * [POST Create a Legal User (SCA)](/api-reference/users/create-legal-user-sca) * [PUT Update a Legal User (SCA)](/api-reference/users/update-legal-user-sca) In this non-SCA scenario: * `UserCategory` is `PAYER` * `UserStatus` is `ACTIVE` * `PendingUserAction` is `null` These are the same endpoints that are used with Owners. **Note – Integrate new endpoints to manage Payers** Payers are not subject to SCA. However, you must integrate the new SCA-enabled endpoints above to register new Payers and update existing ones, regardless of whether they are likely to become Owners in the future. Mangopay intends to deprecate the legacy User endpoints as soon as possible, because they have been made redundant by the new SCA-enabled versions. ## View and list users There is a new version of the [GET View a User (SCA)](/api-reference/users/view-user-sca). For **Natural users**, the response object is the same as the legacy one with the addition of `PendingUserAction` (which is always `null` on the GET endpoint). For **Legal users**, the new GET View a User (SCA) endpoint returns the same data as the legacy one but in the new format: with the `LegalRepresentative` parent object. **Note – UserStatus values apply on both versions** The `PENDING_USER_ACTION` value for `UserStatus` can be returned on both versions of the GET endpoint. On the POST and PUT, it can be only be **triggered** by the new SCA endpoint routes (with `/sca/`). There is no new version of the [GET List Users](/api-reference/users/list-users) because it only returns a summary of key user data, rather than the full object, so no new endpoint is necessary. ## User lifecycle diagram: Categories The introduction of SCA to create an Owner user changes the lifecycle of a user because they cannot become an Owner without SCA. The following diagram shows how SCA impacts the user lifecycle for setting up Payers and Owners. **Note – Not shown in diagram** The diagram below doesn't show: * The PUT Update a User endpoints in all their use cases (e.g. updating Payers) * KYC/B verification, which a user can request once they are an Owner * The possibility of a user being [blocked](/guides/users/blocked-users) (which may happen to Payer or Owner) ## Related resources Read more about redirecting users for an SCA session Read more about SCA