SlimPay Help Center

Start using 3D Secure

In order to enhance the security of customers during online payments, the PSD2 is enforcing a Strong Customer Authentication (SCA), also called 2 factor authentication in Europe. You can visit our documentation on 3D Secure for more information about the subject.

This means that for all customers redirected to our Checkout, we handle their customer authentication inside our hosted page.
In case you are doing a one-off payment by redirecting your customer to our Checkout, in order for your business to benefit most from the Transaction risk analysis exemption, we will now ask you to send us more data about your customer. These data will then be forwarded to the customer’s bank to benefit from an exemption whenever it is possible.

The dates to remember in France: 

  1. October 2020: some transactions above 2000 euros can be declined if not authenticated
  2. January 2021: some transactions above 1000 euros can be declined if not authenticated
  3. 15 February 2021: some transactions above 500 euros can be declined if not authenticated
  4. 15 March 2021: some transactions above 250 euros can be declined if not authenticated
  5. 15 April 2021: some transactions above 100 euros can be declined if not authenticated
  6. 15 May 2021: all transactions will be declined if not authenticated
  7. H2 2021: SlimPay will gradually activate 3D Secure 2
  8. 2021-2022: banks will progressively switch to more modern forms of authentication (fingerprint, push notification...)

SlimPay will activate 3D Secure 1 for all merchants before 15 May 2021, in order to comply with PSD2 requirement.

3D Secure 1 will remain SCA-compliant at least until December 31st 2021.

 

Become compliant with SCA

To handle PSD2 compliance and exemptions, your options are:

  • SlimPay handles the SCA compliance
  • You submit your SCA preference for each transaction

Option 1 : SlimPay handles PSD2 compliance (recommended)

When SlimPay handles the PSD2 compliance for you, we will automatically ask for exemptions on your behalf whenever applicable and challenge the shopper with a strong authentication whenever the bank requires it.

Option 2 : You submit a preference for each transaction

COMMUNICATION-speaker.pngWe recommend to use this option only if you have an extensive knowledge of SCA regulations and the 3D Secure protocol.

Merchants can express their preference regarding whether to apply SCA or not for on-session payments on a per transaction level. However the final decision always stays with the issuing bank, and the result of risk assessment it performs while taking all the transaction data.

In your create-orders request, the payment object has been updated and now accepts a field that will allow you to set your SCA preference for each one-off payments :

Field name Mandatory Description
threeDsPreference  No  Your SCA preference

This field can be set to three values : NoPreference, Challenge, NoChallenge. 

If the issuer denies your exemption request, your shopper will automatically be prompted with a strong authentication.

Merchant Initiated Transactions

In order to benefit from the MIT exemption, PSD2 states that merchants have to seek consent from their payers when storing card aliases, providing them with information about how the merchant plans to use the card alias in the future. 

It is preferable to provide these informations :

  • You plan to charge the payer for a future payment or series of payments
  • The payer is going to be charged at a certain date or frequency in case of recurring payments.
  • The amount of your charges if these are known in advance (fixed amount subscriptions), or the way these are going to be calculated (E-commerce, or metered subscriptions).

There is no fixed way to display this consent seeking to your customers. This will greatly depend on your business activity.

Issuer's Transaction Risk Analysis

In case you are not benefiting from any of the exemptions listed here, you may still benefit from from a TRA exemption if the bank considers your payment low risk. To increase the likelihood of getting this frictionless flow, we recommend to send us a maximum information in the subscriber object of your create-orders request. It now accepts these fields : 

subscriber

Field name Mandatory Description
givenName No Customer's given name
familyName No Customer's family name
email No Customer's email
telephone No Customer's phone
billingAddress No Customer's billing address
shippingAddress No Customer's shipping address 

billingAddress

If you decide to submit this object, you must specify all its fields

Field name Mandatory Description
street1 Yes Building number/name And street name
postalCode Yes The postal code number
city Yes Name of the city
country Yes The ISO-3166-1 alpha-2 country code (e.g. FR)

shippingAddress

If you decide to submit this object, you must specify all its fields

Field name Mandatory Description
street1 Yes Building number/name And street name
postalCode Yes The postal code number
city Yes Name of the city
country Yes The ISO-3166-1 alpha-2 country code (e.g. FR)

Mail order Telephone order (MOTO)

Some businesses such as newspapers or energy companies usually provides subscriptions made by the phone with a teleoperator, or by mail.

These transactions are called MO/TO, short for Mail Orders / Telephone Orders, and are not considered as electronic payments.

As a consequence, MO/TO transactions are totally out of scope of PSD2 and cannot be authenticated with 3D Secure.

In order to benefit from this frictionless MO/TO flow, you have to let us know that your transaction is a MO/TO. To do so, you can specify the origin field in your create-orders request.

Field name Description
origin Two possible values corresponding to your type of order : telephone or mail (The field is case insensitive)
reference  
creditor  
subscriber  
items  
...  

Example request :

{
    "creditor": {
        "reference": "merchant-X"
    },
    "subscriber": {
        "reference": "subscriber-Y"
    },
    “origin” : “telephone”
    "items": [
        {
            "type": "cardAlias"
        }
    ],
    "locale": "FR",
    "started": true,
}

Once your order has been successfully created as MO/TO, if it contained an alias, SlimPay will automatically flag all future payments on this alias as MO/TO.

 

Test cards

In case you want to test your integration in our preproduction environment, we provide test cards that allow to test both the frictionless flow and the authenticated flow. Refer to this page for more details.

 

Was this article helpful?
0 out of 0 found this helpful