> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.mangopay.com/guides/payment-methods/card/3ds/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server. # 3DS 3D Secure (3DS) is an authentication protocol for online card payments developed by major card networks. It reduces the risk of fraud by ensuring the card is used by its true holder through multi-factor authentication. > **Note** > > **Note – Separate from SCA on Owners** > > This article discusses 3DS and how it addresses the SCA requirements during card pay-in flows. > > Mangopay's [SCA on Owners](/guides/sca) feature addresses the same regulatory requirements but on other actions. This protocol involves the following actors: * **The cardholder** - The end user initiating the online payment by card. * **The merchant** - In the case of Mangopay, the platform through which the funds are transiting. * **The issuer** - The bank or PSP of the cardholder who determines whether or not to authorize the payment based on the information received. ## Benefits The 3DS2 protocol benefits all the actors of an online transaction. It contributes to: * A safer, smoother online payment experience for the cardholder, resulting in less checkout abandonment. * Reduced risk of fraud and instances of false decline which strengthens the end user's confidence in the platform. When SCA is applied, the platform may also benefit from a liability shift to the card issuer in case of a fraudulent transaction. * A better process to determine the legitimacy of the transaction for the issuer, which means higher approval rates and fewer fraudulent transactions. The second version (3DS2) facilitates strong customer authentication (SCA) to meet the regulatory technical standards of the European Union's revised Payments Services Directive (PSD2). ## Scope In the pay-in scope, the regulations apply SCA to card transactions that are: * Customer-initiated transactions (CIT) – Meaning that the user is online when the card authorization takes place (as opposed to an MIT ) * Within Europe - Meaning that the issuer and acquirer (which in a pay-in scenario is Mangopay) are both in the European Economic Area (EEA) , the UK, or Switzerland At Mangopay, this means that your platform needs to be ready to redirect the user for 3DS on the following card API calls: * [POST Create a Direct Card PayIn](/api-reference/direct-card-payins/create-direct-card-payin) * [POST Create a Recurring Card PayIn](/api-reference/recurring-card-payins/create-recurring-card-payin) with the CIT payload * [POST Create a Preauthorization](/api-reference/preauthorizations/create-preauthorization) * [POST Create a Card Deposit Preauthorization](/api-reference/deposit-preauthorizations/create-card-deposit-preauthorization) * [POST Create a Card Validation](/api-reference/card-validations/create-card-validation) ### Out of scope SCA doesn't apply on card authorizations in some cases: * Merchant-initiated transactions (MIT), for example during [recurring](/guides/payment-methods/card/recurring) card payments * Anonymous transactions, for example with anonymous cards * Mail-order and telephone-order (MOTO) transactions #### MOTO transactions Platforms can process MOTO transactions with Mangopay by setting the `PaymentCategory` parameter to `TelephoneOrder` (otherwise `ECommerce` by default). The feature requires activation by Mangopay and is available on the following endpoints: * [POST Create a Card Validation](/api-reference/card-validations/create-card-validation) * [POST Create a Direct Card PayIn](/api-reference/direct-card-payins/create-direct-card-payin) * [POST Create a Preauthorization](/api-reference/preauthorizations/create-preauthorization) * [POST Create a Recurring Card PayIn](/api-reference/recurring-card-payins/create-recurring-card-payin) with the CIT payload * [POST Create a Recurring Card PayIn](/api-reference/recurring-card-payins/create-recurring-card-payin) with the MIT payload > **Warning** > > **Caution - Liability with platform for MOTO transactions** > > Because SCA does not apply to MOTO transactions, they are inherently less secure and liability is always with the platform in case of chargeback. ## How does it work? When the platform's app or website starts processing the payment, the following flows can be triggered: #### Challenge flow SCA is required: the platform redirects the end user to the payment page for SCA. This step is mandatory for the payment to succeed. #### Frictionless flow Based on the data sent by the platform, the card issuer identifies the transaction as low risk and does not require SCA. Such cases are called exemptions. 3DS is triggered when: * The platform defines the `SecureMode` parameter of the pay-in to `FORCE`. * Mangopay automatically switches the `SecureMode` parameter to `FORCE`. This may be because the transaction amount exceeds the platform's Maximum Frictionless Amount or due to Mangopay's analysis of the fraud risk. * The issuer applies SCA, regardless of the `SecureMode` value or if the parameter is not present. > **Warning** > > **Caution - The issuer decides when SCA is applied on pay-ins** > > Regardless of the requested flow, the final decision to apply SCA or not rests with the > > issuer > > in a pay-in scenario. > > In other words, you can set the `SecureMode` parameter to `FORCE` and end up being exempted from SCA, or request for an exemption and still have SCA applied. In the response, the need to redirect the user to complete 3DS is indicated in two parameters: * `SecureModeRedirectURL`, which contains the URL you need to use to redirect the user. If 3DS redirection is not required, this parameter is `null`. * `SecureModeNeeded`, which is `true` when the 3DS redirection is required (otherwise `false` when not required). For more information about how to handle 3DS redirection, see: #### [How to](/guides/payment-methods/card/direct/how-to) Learn how to process a card payment ### Authentication type The API returns the `AuthenticationResult.AuthenticationType` property on all relevant transactions, which has the possible values: * `CHALLENGE` – The issuer requested SCA to be enforced (for example, using 3DS). * `FRICTIONLESS` – The transaction was exempted from SCA because an exemption was granted by the issuer. * `DIRECT_AUTHORIZATION` – The transaction was sent to the issuer for authorization without any frictionless or challenge (for example, if SCA doesn't apply). The property reflects both: * The final state of the authentication request that Mangopay made to the issuer, * The decision of the issuer regarding the type of authentication to be enforced (if applicable) A `null` value typically indicates that authentication was not requested (for example, because the request failed before being sent) or a decision was not received. The parameter is returned on the following requests: * [POST Create a Direct Card PayIn](/api-reference/direct-card-payins/create-direct-card-payin) * [POST Create a Recurring Card PayIn](/api-reference/recurring-card-payins/create-recurring-card-payin) with the CIT payload * [POST Create a Recurring Card PayIn](/api-reference/recurring-card-payins/create-recurring-card-payin) with the MIT payload * [POST Create a Preauthorization](/api-reference/preauthorizations/create-preauthorization) * [POST Create a Preauthorized PayIn](/api-reference/preauthorizations/create-preauthorized-payin) * [POST Create a Card Deposit Preauthorization](/api-reference/deposit-preauthorizations/create-card-deposit-preauthorization) * [POST Create a Deposit Preauthorized PayIn](/api-reference/deposit-preauthorizations/create-deposit-preauthorized-payin) * [POST Create a Web Card PayIn](/api-reference/web-card-payins/create-web-card-payin) * [POST Create a Card Validation](/api-reference/card-validations/create-card-validation) * [POST Create a Google Pay PayIn](/api-reference/google-pay/create-google-pay-payin) * [POST Create an Apple Pay PayIn](/api-reference/apple-pay/create-apple-pay-payin) It is also returned on the objects obtained via the GET endpoints: * **GET View a PayIn** (for pay-in types above) * [GET View a Preauthorization](/api-reference/preauthorizations/view-preauthorization) * [GET View a Deposit Preauthorization](/api-reference/deposit-preauthorizations/view-deposit-preauthorization) * [GET View a Card Validation](/api-reference/card-validations/view-card-validation) ### Exemptions applied by issuers > **Note** > > **Note – Different from exemptions applied by Mangopay during SCA on Owners** > > This section discusses the SCA exemptions that may be applied by issuers during card authorization. In a pay-in scenario, Mangopay requests exemptions from the issuer on behalf of your platform, but it is the issue that has the final say on applying the exemption. > > The exemptions allowed by the regulations and applied by Mangopay during its own [SCA authentication features](/guides/sca) are not the same. Acquirers like Mangopay may request exemptions to SCA for some customer-initiated transactions . These exemptions are based on the transactional data collected thanks to 3DS2. Issuers can then either: * Challenge the transaction and force SCA or, * Allow a frictionless flow for the end user. > **Note** > > **Note - No exemption for recurring pay-ins (CIT)** > > SCA is always applicable for CITs when making a recurring pay-in. Exemptions: * Are not automatic, but requested and justified with sufficient information. * Are always requested by acquirers and issuers, not the platform. * Can only be requested once per transaction. On pay-ins, the following transaction types may be exempted from SCA if accepted by the issuer:
Low-amount transactions Transactions under €30 may be exempted until they reach one of the following limits: * More than 5 consecutive transactions * More than €100 in cumulated transactions These limits have no timeframe and transactions with any payment service provider (PSP) count towards the limits. **Note:** Amounts considered as low can vary depending on the bank, currency, and Mangopay's internal rules to ensure a smooth and secure experience.
Low-risk transactions Transaction risk analysis (TRA) tools of PSPs allow the regulatory technical standards to define reference fraud rates under which certain transaction amounts may be exempted. Are considered low risk: * Transactions \< €100 with a PSP fraud rate ≤ 0.13% * Transactions €100-250 with a PSP fraud rate ≤ 0.06% * Transactions €250-500 with a PSP fraud rate ≤ 0.0.1%