> ## 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 Mangopay Account access
> Read about how SCA impacts wallet access endpoints
When a Mangopay Account holder (`OWNER`) requests to access their Mangopay Account, they must authenticate using SCA.
## Scope
Mangopay Account access can be considered as:
* Viewing a wallet balance
* Requesting a list of transactions crediting or debiting a wallet
SCA impacts actions on wallets held by `OWNER` users. SCA is required on first-time access and if more than 180 days have passed since the last SCA authentication for account access.
SCA applies even if a wallet is empty and its balance is zero (and even if there have never been funds in it). SCA also applies to a request to list transactions even if no transactions have ever taken place (the list is empty) or all the transaction requests were not successful.
**Note – Multiple wallets considered same account**
All the wallets held by a single `OWNER` user are considered to be part of their Mangopay Account. This means that SCA only has to be done once to access any of the user's wallets.
## Endpoints impacted
For wallets, the following two endpoints (only) are in scope because they are considered to be accessing the balance of a wallet:
* [GET View a Wallet](/api-reference/wallets/view-wallet)
* [GET List Wallets for a User](/api-reference/wallets/list-wallets-user)
The endpoints to create and update wallets will not be affected by SCA.
For transactions, the following two endpoints (only) are in scope because they are considered to be accessing the account's transaction history:
* [GET List Transactions for a User](/api-reference/transactions/list-transactions-user)
* [GET List Transactions for a Wallet](/api-reference/transactions/list-transactions-wallet)
The endpoints to list transactions or refunds based on other objects (such as for a mandate, card, dispute, etc.) will not be affected by SCA.
## Action required
### 1. Send ScaContext on Owner-initiated wallet access requests
On the 4 endpoints listed above (only), your platform must send the `ScaContext` query parameter on all requests for users whose `UserCategory` is `OWNER`.
The `ScaContext` parameter has the values:
* `USER_PRESENT` – The user is taking the SCA-triggering action of accessing their wallet. The platform must [redirect the user](/guides/sca/session) using the `PendingUserAction.RedirectUrl` returned so that the user can complete the SCA session (unless exempted because a successful SCA session for wallet access occurred in the last 180 days, 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.
**Caution - ScaContext default value changing**
On wallet access endpoints, the default value for `ScaContext` is changing to `USER_PRESENT` on **Dec 15, 2025** (Dec 1 in Sandbox).
From this date, if the `PendingUserAction.RedirectUrl` value is returned, then you need to redirect the user to perform SCA.
With approval from Mangopay, your platform may be able to use the `USER_NOT_PRESENT` value provided you also have a legal proxy in place with the user and the user's consent to access wallet balances and transactions on their behalf (see below).
The `ScaContext` parameter should be considered mandatory and the relevant value must be sent on all wallet access requests for `OWNER` users. You do not need to send `ScaContext` if the `UserCategory` is `PAYER`.
#### USER\_NOT\_PRESENT requires proxy
To use the `USER_NOT_PRESENT` value, your platform must put in place a proxy in your legal documentation, and you must obtain the User's consent. For more information, see the [proxy management](/guides/sca/proxy-management#) guide.
The introduction of Mangopay's proxy management system makes it possible to apply SCA correctly in all cases. If the proxy action is activated for your platform and you send `USER_NOT_PRESENT`, but the user hasn't given consent via the hosted SCA experience, then the request will fail.
In this case, your platform has two options:
1. Obtain consent from the user by calling [POST Manage proxy consent for a User](/api-reference/users/manage-proxy-consent), and then retry the transfer with `USER_NOT_PRESENT`
2. Retry the action with the user on session to authenticate, by setting `ScaContext` to `USER_PRESENT` and redirecting the user on the `PendingUserAction.RedirectUrl` returned
The rest of this guide describes the `USER_PRESENT` case.
#### Example API request
On the GET endpoints for wallet access, the `ScaContext` is a query parameter.
So, for example, a request to the [GET List Wallets for a User](/api-reference/wallets/list-wallets-user) would be made on the following URL (in Sandbox):
### 2. Redirect the user for SCA if required
For requests made with `ScaContext` set to `USER_PRESENT`, the user is on session and can perform SCA. SCA for wallet access is only required once every 180 days. This means that if SCA was successfully performed by the user within the last 180 on any of the 4 endpoints above (and for any of their wallets), then SCA is not required.
If the 180-day exemption was applied (for `USER_PRESENT`), then the `RedirectUrl` is not returned because no redirection is necessary.
If SCA is required for the wallet access request, then a call to any of the 4 endpoints above will return a **401 - Unauthorized**.
The `RedirectUrl` value needed for the user to be able authenticate is returned in the `WWW-Authenticate` response header, in the following format:
#### Example API response
```HTTP 401 response header theme={null}
WWW-Authenticate: PendingUserAction RedirectUrl=https://sca.mangopay.com?token=0193d02f30df7a188c51cf890a191d21
```
Mangopay has implemented a 401 response in this scenario, rather than a 200, for a few reasons:
* The 4 endpoints impacted by SCA do not all return the same data type: the [GET View a Wallet](/api-reference/wallets/view-wallet) endpoint returns a JSON object while the others return an array. The 401 response allows them all to return the `RedirectUrl` in the same way.
* A 401 response is suitable thanks to its dedicated `WWW-Authenticate` response header.
* In a wallet access scenario, the data response is itself the fulfillment of the request. By contrast, in a transaction scenario, Mangopay has a precedent of accepting the request and then asynchronously returning a success or failure outcome.
Your platform needs to retrieve the `RedirectUrl` value to redirect the user.
**Note – Encode and add your returnUrl 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.
For more details, see [How to redirect a user for SCA](/guides/sca/session#how-to-redirect-a-user-for-sca).
The individual must authenticate on the Mangopay-hosted webpage within 10 minutes of the API response. After the SCA session, the user is returned to your specified `returnUrl`, regardless of the outcome.
Once SCA is successful, subsequent calls to any of the above endpoints return the wallet or transaction data for the next 180 days, because SCA can be exempted, and then SCA redirection will be required again.
#### Handling wallet access outcome
There is no webhook notification for the SCA session itself, so in the case of wallet access you should retrieve the `controlStatus` query parameter appended to your `returnUrl` by Mangopay after the SCA session.
You can retry the wallet access by calling the relevant GET endpoint again.
## Testing
### SCA triggers in Sandbox
In Sandbox, SCA is triggered on the [4 endpoints listed above](#endpoints-impacted) if all of the following are true:
* The user has the `UserCategory` value `OWNER`
* The user's type is Natural or Legal (all `LegalPersonType` – `BUSINESS`, `SOLETRADER`, `ORGANIZATION`, or `PARTNERSHIP`)
* `ScaContext` is `USER_PRESENT`
* The last successful SCA session on any one of the 4 endpoints was more than 180 days ago (or has never happened)
In Sandbox, SCA is not triggered if any of the following are true:
* User has the `UserCategory` value `PAYER`
* Until Dec 1, 2025: `ScaContext` is `USER_NOT_PRESENT` or not sent (in which case it is `null`)
* The last successful SCA session on any one of the 4 endpoints occurred within the last 180 days
#### 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.
### Postman
The Mangopay API Postman collection contains a dedicated folder for SCA on transfers and wallet access. The collection contains examples of using the `ScaContext` query parameter with the value `USER_PRESENT` on wallet access endpoints, and a script for extracting the `RedirectUrl` from the 401 response.
See the [Postman](/postman) guide for details on how to fork the collection and set up your environment with your `ClientId` and API key.
## Related resources
Read more about redirecting users for an SCA session
Read more about proxy management for USER\_NOT\_PRESENT