3DS2 integration

1. SecureMode redirection

What has changed

Previously, a transaction (PayIn or PreAuthorization) would generally not be subject to strong customer authentication if SecureMode=DEFAULT and the payment amount was inferior to your 3DS limit. Since 1st January 2021, we can no longer guarantee this frictionless payment experience – including on low amount transactions for card verification.

Mandatory integration

Therefore, your website or app must be able to handle a redirection to the 3DS protocol on any Card Direct PayIn or PreAuthorization. An issuer can apply SCA to any transaction, even to flows on 3DS1 servers (which remain PSD2 compliant).

If SecureModeNeeded=TRUE, redirect the user to SecureModeRedirectUrl.

Scope

The scope of this change applies to the following endpoints:

• PreAuthorization
• Card Direct PayIn

Full SecureMode flow

1. Your app or website creates a PayIn or PreAuthorization API call
2. 3DS is triggered in one of three ways:
   1. You select SecureMode=FORCE in the API call
   2. MANGOPAY triggers SecureMode=FORCE automatically because the transaction is superior to your Maximum Frictionless Amount (previously known as the 3DS limit)
   3. The issuer applies SCA to the transaction, regardless of the SecureMode value. This trigger is new from 1st January 2021.
3. When 3DS is triggered, the response of the API call will display SecureModeNeeded=TRUE
4. When SecureModeNeeded=TRUE, you redirect the user to the SecureModeRedirectUrl. This redirection is mandatory for the payment to succeed.
5. Once the authentication phase is completed, the user is returned to the SecureModeReturnUrl you provide
   
   

SecureMode values under 3DS2

MANGOPAY will not change the logic of SecureMode on 3DS1 flows. Once we have activated your flows on 3DS2 (which requires the mandatory transaction data outlined on this page), the following SecureMode values will be available, including the new NO_CHOICE value.

MANGOPAY agrees a Maximum Frictionless Amount (previously 3DS Limit) with each client, above which we automatically set SecureMode=FORCE. By default this limit is €50.

Below this limit, your options are:

1. Keep DEFAULT (following the same logic as on 3DS1)

   • Liability remains on your side (as on 3DS1)
   • Rate of frictionless payments should be close to what it is on 3DS1

2. Replace DEFAULT with NO_CHOICE (new option for 3DS2)

   • Liability is no longer on your side
   • The frictionless rate will depend on market readiness
     
     
     

2. Transaction data

Mandatory integration

Scope

The parameters BrowserInfo and IpAddress must be included on all calls to the following endpoints:

• Card Direct PayIn
• PreAuthorization

2.1. BrowserInfo

Please note that this information is collected:

• On a website: directly by the user’s browser.
• On a mobile app: a webview needs to be opened to collect information on the browser before proceeding to the payment. Once this is done, proceed in the same way as for a website.

{
"BrowserInfo": {
        "AcceptHeader" : "application/json,text/javascript,*/*;q=0.01<", 
        "JavaEnabled": true,
        "Language":"fr",
        "ColorDepth": 32,
        "ScreenHeight": 667,
        "ScreenWidth": 375, 
        "TimeZoneOffset": "-120",
        "UserAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 13_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148",
        "JavascriptEnabled": true
}

What to send

What to collect

2.2. IpAddress

What to send

IP address (V4 or V6) of the end user.

   $.ajax({
        url: "https://api.ipify.org?format=json",
        dataType: "json",
        success: function (data) {
            ipAddress = data.ip;
        }
    });

2.3. Objects: Billing / Shipping

Optional integration

As an exemption to SCA is granted based on a risk analysis, the more transaction data sent with each call, the higher the likelihood that an exemption will be granted.

Scope

The objects Billing and Shipping may be included on all calls to the following endpoints:

• PreAuthorization
• Card Direct PayIn
• Card Web PayIn

Considerations

The objects Billing and Shipping contain information relating to the user’s billing and shipping address respectively.

• If both the Billing and Shipping objects are empty, we will automatically complete them with the information from the User object before the call is sent to the issuer.
• If the Billing is supplied but the Shipping is empty, we will automatically complete the Shipping object with the fields supplied for Billing.
• If the Shipping is supplied but the Billing is empty, we will automatically complete the Billing object with the fields supplied for Shipping.

In any case, the values sent by MANGOPAY will be available in the call response and via the GET call.

Format (same for both)