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.

SlimPay's API and Checkout will be ready for SCA roll-out by January 1, 2021. 

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. April 2021: all transactions will be declined if not authenticated
  5. end of 2020/beginning of 2021: SlimPay will enable 3D Secure 2 for all merchants
  6. 2021-2022: banks will progressively switch to more modern forms of authentication (fingerprint, push notification...)

In this last phase, banks will progressively move towards a 2 factor authentication with 3D Secure 2. Our Checkout will stay compliant with both 3D Secure 1 and 3D Secure 2 during this phase.


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 : 


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 


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)


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)

If you have a Mail order or Telephone order flow in your business, you can benefit from the MOTO exemption. For example merchants which take orders via a call center will fall under this exemptions and will not need to authenticate their payer during the checkout session.

In order to benefit from the exemption, let us know that your order is a MOTO order, by specifying 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)

Example request :

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

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