PSD2 EU Compliance

The new Payment Services Directive 2 is an EU regulation which will require changes to the checkout and booking process for all transactions involving a credit card issued by an EU state.

The aim of this regulation is to help reduce online fraud and protect customers. It will come into effect in September 2019 and all EPS partners can be affected by it if they handle the affected payment types.  If affected payments are not compliant by that date, they fail as EU banks will reject these transactions. Banks will reject payments regardless of whether the partner is based in the EU or not.

This page explains how supported EPS payment types will be impacted and what actions partners can take to be compliant when serving their customers. If you would like to learn about the directive in more details, please review the legislation on the official European Commission site.

Compliance Requirements

The steps to enable compliant transactions in the EU will vary depending on who is the merchant of record and how payments are made to EPS.

Partner is Merchant of Record

Expedia Affiliate Collect

Bookings that use EAC are unaffected by the PSD2 regulations – no payment process or API integration changes with EPS are needed to reach compliance. However, you may be impacted by the regulations if you are the merchant of record and charge customer’s credit card, debit card, or other form of payment within the scope of the EU regulations. The regulations likely require you to support a PSD2-compliant version of Two-Factor Authentication in the payment process. Please reach out to your payment processor to learn more about their capabilities to help merchants reach PSD2-compliance and avoid failed transactions in September 2019.

Partner Cards

If your company is the merchant or record and pays EPS with an EU-issued credit or debit card owned by your company, you may be impacted by the regulations. The set of PSD2-compliant cards is:

• Single-use virtual cards, issued in the EU.
• Corporate cards issued to your company (not issued to a person), issued in the EU.
• Any card issued outside the EU.

You may also be impacted by the regulations if you charge your customers’ credit card, debit card, or other form of payment within the scope of the EU regulations. The regulations likely require you to support a PSD2-compliant version of Two-Factor Authentication in the payment process. Please reach out to your payment processor to learn more about their capabilities to help merchants reach PSD2-compliance and avoid failed transactions in September 2019.

If the above PSD2-compliant partner cards are not preferable, your organization can request an exemption directly from the bank that has issued your partner card. If an exemption is granted, transactions on that card will not require authentication except for a possible one-time online verification using two-factor authentication (2FA). This one-time requirement can vary per bank. Please note that, obtaining an exemption can be lengthy process and it will also mean that your bank may hold you liable for fraudulent payments. 

EPS is the Merchant of Record

If your company uses EPS as the merchant or record by sending customer cards to EPS, you may be impacted by the regulations. When customers book online, without a retail agent, the regulations require that EPS let customers verify whether they initiated the payment.  The PSD2-comliant process for this requirement is Two-Factor Authentication (2FA) during the payment process. Partners that want to use EPS as the merchant of record with any EU-issued credit or debit card, will need to adopt our Rapid solution for 2FA available in Rapid v2.2.

However, transactions that are booked with through a retail agent or call-center agent are exempt from the 2FA requirement. Compliance for these transactions only requires an explicit indication that that booking was made with the assistance of an agent.

Hotel is the Merchant of Record (Hotel Collect)

If your company uses Hotel Collect, you may be impacted by the regulations.  There are circumstances where a hotel may try to charge a customer’s card without the customer present (e.g. “no show” fees or deposits). These charges are not compliant without Two-Factor Authentication (2FA) being performed prior to the charge.  Partners that want to use Hotel Collect for customers using an EU-issued credit or debit card, will need to adopt our Rapid solution for 2FA available in Rapid v2.2.

Rapid and Two-Factor Authentication

How does it work?

Partners that use EPS MOR or Hotel Collect with customer cards can adopt EPS’s API solution to generate bookings that are compliant with the regulations.   The APIs support PSD2 compliance by supporting Two-Factor Authentication with 3DS 2.0 in the booking flow.  With 3DS 2.0, we support risk-based authentication, which reduces friction with customers by granting the banks discretion about when to challenge customers with 2FA and when to not.   

The solution for 2FA is comprised of three distinct components:

• An iframe that partners add to the checkout page. It’s used to host an issuing bank’s 2FA experience for the customer.
• A new client-side JavaScript library that resides on the checkout page. It’s used to collect browser data, communicate with the iFrame, and display the 2FA experience within the iframe.
• New Rapid APIs that accepts payer information for the bank and completes the booking after 2FA. 

When using the JavaScript and Rapid APIs together, the booking flow with 2FA will now include a few additional steps before and after the Book API is called.  Below is a diagram that depicts this updated booking flow.

During each step of the revised Booking flow, the output of one step contains data that is used as input into the next step.  Data will need to be passed between the JavaScript (on the browser) and Rapid APIs.

Integration Component Details

Browser iFrame

The iframe, placed in the checkout experience, hosts a URL owned by the customer’s card-issuing bank. This URL will display the 2FA experience to the user and transfer any customer-supplied information directly to their bank. The iframe should be hidden initially, with the ability to overlay it on top of the page when a 2FA challenge is required after a booking attempt.

The iframe HTML element can use the sandbox attribute to enable extra restrictions on the hosted content but it must contain the following permissions: allow-scripts, allow-forms<code>, and allow-same-origin.<br>

sanbox = "allow-scripts allow - forms allow-same-origin"

Browser JavaScript Library (new)

This library is added to the checkout page and is invoked at the time of booking to support the 2FA process.  The library’s APIs support the capabilities described below.

Automatic Collection of Customer’s Device-Information

Before a booking attempt, information about the customer’s device must be collected to prepare a booking for 2FA.  It is later sent to the customer’s issuing-bank for review so the bank can assess risk  and decide if 2FA is required for the transaction.  In accordance with the 3DS 2.0 specifications, following data will be collected from the customer’s browser: language, color depth, screen height, screen width, time zone, user agent, and whether Java is enabled.

Display the 2FA experience in the Browser iframe

After a booking attempt, the library is used to display iframe overlay and load the bank’s  content into the iframe.  During the 2FA process, the bank’s content may collect additional information about the customer’s device to support their risk assessment. This process is needed to complete a booking.

Rapid APIs

Rapid v2.2 includes new APIs that work in conjunction with the client-side JavaScript library.  The APIs now support the capabilities described below.

Registration of Customer and Payment Details

Before a booking attempt, additional information about the customer must be collected to prepare a booking for 2FA. This data includes details of the customer’s account with the point of sale and the customer’s payment.  This data is later sent to the customer’s issuing-bank for review so the bank can assess risk  and decide if 2FA is required for the transaction.  Learn more by reviewing Create Payment Session API in Rapid v2.2+.

Completion of a Payment and Confirmation of Booking

After a booking attempt with Rapid and the 2FA process is completed on the browser, Rapid must be invoked once more. Behind the scenes, we’ll confirm that the 2FA was actually successful, so the booking can be confirmed. Learn more by reviewing the Complete Payments Session in Rapid v2.2+.

Booking Flow Involving JavaScript and Rapid APIs

Overview

If 2FA is enabled in the Partner Portal, the Price Check API will return a link to the Create Payment Session API instead of the Book API. Below is a diagram of the API call sequence that will be required after a booking is initiated by a customer.

Booking

When a booking is prepared for 2FA, it may not always be required. The need for 2FA is determined by the customer’s bank during the transaction and is indicated in the in the Create Booking API response.

Below is a diagram of the API call sequence that be required when using Hold and Resume.  

More information

Documentation of the end-to-end integration process is planned for April. This documentation will include details of the JavaScript Library and how it can be used in combination with the already-documented Rapid v2.2 APIs. 

For further information on the technical requirements for the 2FA experience, review the EMVCo’s “3-D Secure Protocol and Core Functions Specification”

Preview EPS Rapid 2.2 Documentation. 

You can now review documentation for the upcoming version of our EPS Rapid API. Review the schema, start coding and test against our end-points in preparation for go-live in June 2019. Go to our EPS Rapid 2.2 page to learn more.