Skip to main content

3DS

PSD2​

The second Payment Services Directive (PSD2) will be mandatory compliance as of December 31, 2020. This directive affects payments within the European Economic Area and requires all payments where the user is present to be carried out securely via 3DS. In addition, it will no longer be possible to launch unsecured payments without the presence of the user unless the card has made at least one secure payment via 3DS in the past.

The following types of payment services will be affected by PSD2 as of December 31, 2020:

  • REDSYS
  • EVOSNAP
  • CREDORAX
  • CLEARHAUS

Regulations​

PSD2 will be mandatory as long as two conditions are met:

  • The payment service is located within the Eurozone.
  • The card has been issued from a country within the Eurozone.

The first condition will always be met for the payment services mentioned above, so the only factor that can influence the application of the PSD2 regulation is the country of origin of the card. Cards from a country outside the Eurozone are exempt from PSD2 compliance. However, as we cannot know until the time of payment whether the card is exempt or not, we recommend that all payments are made securely via 3DS when the user is present.

If an unsecured payment is attempted and cannot be completed due to PSD2:

  • If the user is present (payment via payment letter) the user will be redirected to 3DS.
  • If the user is not present (direct-payment) the API will return a link to which the user must be redirected to perform the 3DS. These types of payments are also known as webservice payments or MIT (Merchant Initiated Transactions) payments.

We recommend using tokenized payments once the card has been tokenized, as these always use 3DS and allow you to take advantage of all the benefits offered by PSD2. Non-secure webservice payments should only be used when the user is not present, for example, to charge a subscription.

Advantages​

Until now, secure payments always used 3DS version 1.0, which requires the user to enter a code received on his cell phone, leading to friction that could result in the user abandoning the purchase process. The new versions of the 3DS version 2 protocol allow this step to be skipped in certain circumstances:

  • The amount of the transaction is low (less than €30) or the total amount of the last 5 transactions does not exceed €100.
  • The merchant's fraud threshold is low and the transaction does not exceed 100, 250 or 500€.
  • Sufficient personal data of the user is provided, such as name and surname, email, shipping address, contact cell phone number...

The above circumstances are called exemptions and Paylands requests them whenever possible to minimize friction during 3DS.

If any of the above conditions are met, it is possible for the payment to be finalized without user intervention. This is known as frictionless 3DS payment. If on the other hand the above conditions are not met the user must perform a challenge, which is one of the following actions:

  • Enter a code that you receive on your cell phone, known as OTP (One Time Password).
  • Confirm the payment from your bank's mobile application.

Regardless of what happens, the payment will be considered authenticated through 3DS.

Payments without the presence of the user​

In general, the user must be present at the time of payment and the payment must be made securely with 3DS. So how can payments be made without the user being present, such as subscriptions? PSD2 provides for exceptions as long as the card has been used before in a secure payment.

Only some payments can be made without the presence of the user:

  • Recurring or installment payments (subscriptions, loans...).
  • No-show in hotels

These payments will be carried out by WebService. We recommend indicating the reason for the payment when creating the order in the extra_data.cof.reason parameter. These are the possible values for this field:

  • RECURRING (recurring payments, subscriptions...).
  • INSTALLMENTS (installment payments, loans...)
  • NO_SHOW (when a person does not show up at the hotel on the day of the reservation)
  • DELAYED (payments for services offered for which the amount is not known at the beginning: minibar, repairs, fines...)
  • OTHER (when the reason for the charge is not known a priori. For example, in the case of a hotel that does not know if it will have to charge the reservation when the user shows up, which would be RECURRING, or a NO-SHOW if the user does not show up).

If the aforementioned conditions are met, the payment will be finalized normally without the need for the user to intervene. If on the other hand any of those conditions are not met or it is imperative for the user to authenticate, the API will return a payment link which can be sent to the user to finalize the payment via 3DS. This decision as to whether the user must authenticate a MIT transaction is 100% up to the bank, and is made based on its own internal rules. Paylands will always send as much information as possible to the issuing bank to try to finalize the transaction without requiring user intervention, but the final decision will be made by the user's own bank.

The first payment with a card must always be made through the payment card or tokenized so that the user is authenticated for the first time and can opt for this method in subsequent payments. Payments without the presence of the user are reserved only for merchant initiated payments, also known as MIT (Merchant Initiated Transaction).

How to adapt to the changes​

If your merchant makes only secure payments via 3DS you don't need to do anything. Once the date arrives, Paylands will change the way payments are processed. Customers will notice that the process is slightly different depending on their card issuing bank, however as a merchant you will not notice any difference.

If, on the other hand, you make non-secure payments via WebService when users are not present at the time of payment, you will need to support secure payment methods, such as the payment card or tokenized payment. You will also need to correctly handle the WebService payment response when the payment link is returned.

All merchants will start to operate under the new regulation as of January 1, without the need to take any action. However, if you want to get a head start and have your merchant start operating with PSD2 before the deadline, you can send an email to soporte@paylands.com indicating your FUC (8-9 digit merchant code) and the bank through which your merchant operates.

Extra information​

To increase the likelihood that the user will not need to authenticate to finalize the payment, extra data can be optionally sent. This data should be included in the extra_data field when creating an order in the format detailed in section "Pagos > Orden de pago".

Frequently Asked Questions (FAQ)​

Will I be able to make payments without the presence of the user if the secure payment took place before the regulation came into force?

Yes, for REDSYS and EVOSNAP services. For the other services, it will be necessary to make a secure payment again before being able to launch payments without the user's presence.

Can I launch a 3DS payment to authenticate the user for one service and then launch a payment without the user's presence for another?

No. It is necessary to authenticate the user at least once per payment service. The services can be different as long as they are of the same type.

Exemptions​

We currently support Low Amount (LV) and Risk Analysis (TRA) waivers in the Redsys payment service. To request them, simply provide the following information in the extra_data field when creating the order:

"extra_data": {
        ...
        "sca": {
            "exemptions": ["TRA", "LV"
        },
    }

It is also possible to request that no exemptions be applied by leaving the value of exemptions as an empty list:

"extra_data": {
        ...
        "sca": {
            "exemptions": []
        },
    }

If the value of exemptions is not explicitly stated, by default the Low Amount (LV) exemption will be requested if it meets the stated requirements. After payment, if any exemption has been requested, its name will be included under the order.threeds_data.exemption key. If no exemption was requested, or could not be requested, its value will be null.

"threeds_data": {
      "version": "...",
      "flow": "...",
      "sca_requested": ...,
      "status": "...",
      "eci": "...",
      "exemption": "TRA"
  }

Finally, the fact that an exemption is requested does not imply that it has been accepted. In order to better understand whether an exemption was accepted or not, the threeds_data.flow field can be viewed. If the exemption was requested but its value is CHALLENGE_ONLY or FULL, it means that it was not accepted. If its value is FRICTIONLESS or FINGERPRINTING_ONLY, it means that it may have been accepted. There is no way to know 100% if an exemption was accepted, only if it was rejected.

There is also no way to know if a waiver was accepted by the issuer (user's bank) or the acquirer (merchant's bank).

Requirements​

Exemptions must meet certain requirements before they can be requested. Up to 2 exemptions can be requested, of which at most one will be requested. Exemptions are requested in the order in which they are indicated on the request. The requirements to apply for each exemption are:

General requirements​

  • The card must belong to the European Economic Area (EEA).
  • The payment service must support the exemption request (currently only supported by Redsys).
  • The terminal associated to the payment service used must have the waiver to be requested activated.
  • The currency used must be the Euro.
  • The payment must be secure and the version of 3DS must be 2.1 or 2.2.
  • The card must have at least one successful payment in the last year.

Risk Analysis (TRA)​

  • The amount must be equal to or less than £500, £250 or £100 depending on the merchant's average fraud rate equal to or less than 0.01%, 0.06% or 0.13%, respectively.
  • To take full advantage of this exemption it is recommended to indicate the following information in the extra_data field:
    • Email
    • Telephone number
    • Billing and shipping address (can be the same).

Low amount (LV)​

  • The amount must be less than or equal to 30€.