PSD2 in Real Life: How the New EU Payment Service Directive Works for Hotels and Online Bookings

By now, you've likely heard about the new credit card payment service directive and its potential repercussions in our industry. What you may not know, however, is that PSD2 is nothing new in fact, it was first implemented back in 2015, even though not all its parts were enacted simultaneously. Strong Customer Authentication, particularly, was meant to come into force only on September 14th, 2019, four years after the approval of the directive. So, you'd imagine the industry to be ready, wouldn't you? Well, not quite...

KNOWLEDGE, POSSESSION, AND INHERENCE

So, what is PSD2? At its core, it is merely an updated version of the current payment service directive. With the introduction of PSD2, for buyers to shop online with credit cards (or to make banking transactions), they will have to provide two out of three distinct means of authentication at the time of purchase. The first type includes some type of knowledge, such as a password or PIN. The second type includes some form of possession, such as a phone or credit card. And the third type includes an inherence, such as a face scan or fingerprint. This two-factor authentication method is known as Strong Customer Authentication (SCA), and its primary goal is to increase online transactions' security and reduce frauds and chargebacks. PSD2 will affect all the transactions involving EU card issuers (including the UK, for the moment).

WHAT WILL A POST-PSD2 INDUSTRY LOOK LIKE?

Thanks to this additional second layer of security, SCA has the potential to make credit card online transactions significantly safer, and it may even have a positive effect on the buyer's user experience. Currently, once users enter their credit card details, they are redirected to what is known as a 3D Secure page. The problem is that these intermediate pages have not been designed with mobile phones in mind, dramatically increasing the dropoff rate (between 5% and 15%, according to Worldpay). Under PSD2, on the other hand, the experience will be more mobile-friendly, theoretically increasing conversion rates. Still, some implications could (and, very likely, will) negatively affect hotels' day-to-day operations.

The good news is that, due to the lack of merchant readiness, a delay on the original deadline has been granted. Why? Well, in June 2019, with only 3-months before the September 14th deadline, banks were required to publish their APIs; only one-third did so and, in September 2019, over one-third of these APIs still do not work properly, creating a challenging environment for the third-party providers trying to integrate. More recently, banking platform and data provider Tink tested APIs from more than 2,000 banks. The result? None of them met new regulatory standards. The United Kingdom already conceded 18 extra months, and in October, the European Commission will announce the new compliance date for the other countries.

The European Banking Authority, in an official document stated that "The European Banking Authority (...) accepts that, on an exceptional basis and in order to avoid unintended negative consequences for some payment service users after September 14th, 2019, (...) may decide (...) to provide limited additional time to allow issuers to migrate to authentication approaches that are compliant with SCA". Similarly, UK's Financial Conduct Authority stated it will not take "any action against firms that are not ready for the rules in September, as long as there is evidence that they have taken the necessary steps to meet its longer transition plan, which will require firms to fully comply by March 2021." So it is not so far-fetched to think that the new EU compliance date will be somewhere in late 2020/early 2021.

MR. SMITH BOOKS A HOTEL ROOM: WHEN DOES SCA APPLY?

Mr. Smith books a hotel room online. At the moment of payment, he enters his credit card number and proceeds to checkout. Once the credit card data are entered, the transaction will have to pass a test called the Transaction Risk Analysis (TRA), to evaluate if SCA is needed or not. Even under PS2D, some transactions will still be exempted from SCA: contactless payments and all the transactions where the credit card owner is physically present at the moment of payment, for example, will not fall under the regulation; so, if Mr. Smith arrives at the hotel to book his room, and he is present during the transaction, then no authentication will be needed. Purchases made over the phone or via email will follow the same logic, so if Mr. Smith calls the hotel and gives his credit card data over the phone, there will be no need for SCA. Remember, exemptions are numerous, and many variables can apply even to similar cases, but, for the purpose of this article, we will only cover the main ones.

Back to Mr. Smith: the TRA test is now deciding if a double authentication is needed. The test evaluates the risk of fraud, ranging from low to high. If the transaction is for an amount under 30€, for example, no authentication is needed, provided that the same card was not used for more than five transactions (or for a total of over 100€) over the last 24 hours. So, if the room or upgrade costs 29€, and Mr. Smith did not buy anything else the same day, then no authentication is needed. Note that, even with exempted transactions, the bank will always have the final say, so it could decide that SCA is required even for low-risk purchases.

Now, Mr. Smith still needs to complete the payment for the room he wants to book at the start of the example. The total amount is 500€, and he never booked this hotel before. The TRA test decides that this is -potentially- a risky transaction, and requires Mr. Smith to double-authenticate it. He will, therefore, need to provide two out of the three types of accepted authentication. Here are a two examples:

• By unlocking his phone ("possession" = something "he owns") with his fingerprint (“inherence" = something “he is”)
• By inserting a password ("knowledge," = something "he knows") and recognizing a trusted mobile device ("possession" = something "he owns").

Under PSD2, the sole one-time PIN via SMS authentication on an unlocked phone will not be enough anymore, as a thief could have access to both by merely stealing the phone, making the two factors fall under the same category (proof of "possession"), and they will still be able to provide at least one more type of authentication.

PSD2 IN HOSPITALITY

Some people already refer to PSD2 as "GDPR on steroids." Maybe. What is certain is that the topic is vast and full of ramifications so, if you're looking for an exhaustive read on the topic, I suggest you take a look at this piece by Pablo Delgado and Daniel Badenas from Mirai. This article focuses less on theory but effectively deconstructs possible "what-if?" hotel scenarios to illustrate how PSD2 could look like in real life. First of all, let's start by reassuring you: unlike GDPR, hotels cannot be fined for not conforming with the directive. Only the final payment platform and merchant model businesses could be held responsible for breaches. Anyhow, it does not mean that the introduction of PSD2 should be taken lightly, as there are (many) cases where your day-to-day operations will have to adapt accordingly.

Here are some, most-likely, scenarios:

• MR. SMITH BOOKS A FLEXIBLE OR A NON-REFUNDABLE RATE ON AN OTA (MERCHANT MODEL)

For reservations received through an OTA with the merchant model (the OTA collects the money from in behalf of the hotel), existing processes will not change. In this case, the OTA is the one collecting money from the final guest and providing hotels with a virtual card, so hotels will not need double authentication to process the payment.

• MR. SMITH BOOKS A NON- REFUNDABLE RATE ON AN OTA (AGENCY MODEL)

When it comes to non-refundable reservations received through an OTA with the agency model, your hotel will have to (quite drastically) change its internal processes and systems to ensure the payment is validated: first of all, the hotel must process these payments via an online payment gateway that is PSD2-complaint. If you do not have a gateway with that security compliance, the alternative is not ideal: you don’t authorize the card for any portion of the rate and cross your fingers that the guests eventually arrive. If and when the guest arrives, then the payment can be treated as "card-present," skipping SCA.

Nonetheless, hotels will not be able to bill any no-shows or penalties for late cancellations: manual charges on physical card readers won't work, as the single credit card number could not be enough to process the payment, and guests could still dispute the charge and lead to a potential chargeback for the hotel. To address the issue, Expedia recently launched a free cancellation fee management tool: "When a traveler makes a Hotel Collect booking, Expedia Group validates the customer card and captures the necessary authentication information. An Expedia Virtual Card (EVC) number will be provided to you, so you will no longer see a guest card number. [If Expedia is not able] to charge the card because it doesn't have sufficient funds or has become invalid, [it will] remove the fee and commission on the reservation.

• MR. SMITH BOOKS A 4-MONTH-EARLY-BIRD FLEXIBLE RATE ON BRAND.COM

Even though travelers' booking windows get shorter every year, early bookings are still frequent in specific cases (beach resorts, MICE hotels...). These reservations usually come with great perks for the guests, such as heavily discounted rates but, under PSD2, processing the payment can be challenging, as SCA comes with an expiration date: double authentication only lasts for 90 days, so hotels will have to acquire multiple authentications for the same reservation. A workaround is to utilize Merchant Initiated Transactions (MIT), as long as the terms and conditions are clear on the booking engine because the guest's payment information will have to be already present (and authorized) in the hotel's PMS, booking engine, or CRS. Even though every initial purchase WILL need to be authenticated via SCA, future transactions with the same card could be considered MIT, thus exempted from SCA requirements. This is a particularly favorable scenario for loyalty programs’ members, for example.

• MR. SMITH BOOKS A FLEXIBLE RATE ON BRAND.COM, BUT IT IS A NO-SHOW

According to a VISA study, the hotel industry average no-show rate is "one-to-two percent of all reservations," meaning, "an estimated expense to the hotel industry of $50 to $100 million per year". Under PSD2, you will not be able to process guests' credit cards if they're not physically at the hotel (card-present), or if they do not double-authenticate the transaction (card not present). It is improbable that a guest will agree to pay for something they did not use, so the hotel is caught in a bind. Unless the no-show penalty has been charged during the booking process (which is rare), then it is unlikely that the no-show guest will double authorize it. The solution is to use the MIT workaround.

CONCLUSIONS:

These are just a few of all the possible scenarios, as more will surface once the directive is enforced. At a first look, it seems that -from a hoteliers' perspective- the cons outweigh the pros. Our suggestion is to implement the following strategy:

1. Implement a card-not-present payment gateway to make day-to-day operations less burdening. If you have a PMS, you likely already have a gateway, but it won't be of any help if you do not have access to the guest's physical card;
2. Offer guests the option to store their payment methods for future use, exempting the transaction from SCA;
3. Integrate alternative forms of payments in your ecosystem as they do not fall under the PSD2 directive. Even though underused in our industry, payment methods such as Apple Pay, Google Pay, Amazon Pay, WeChat, and AliPay are on the rise.