How PSD2/SCA will affect Vacation Rentals: exceptions will be the rule

If this is the first time that you are learning about PSD2, we recommend that you start with the first piece in this series of articles: What is PSD2 and when will it be implemented?This will help you understand the basics and help you to understand the next ones.

The most important thing is that you understand that this issue affects you and therefore you should be well informed and start preparing yourself. From AvaiBook we are already doing this: we are adapting our software to PSD2 to meet the requirements and suggestions in time. We recommend you to keep up to date with our blog; in the next few days we will publish more information that might interest you.

 

PSD2/SCA explained in the simplest and most summarized way possible:

As of January 1st, 2021, the rules governing online payments will change. These regulations require enhanced authentication (SCA), i.e. 3DSecure 2, for online payments within the EEA. For “non-presential” online payments, certain exceptions are established.

 

The PSD2 reveals two distinct payment situations:

The first is that of on-line payments where “the payer is face-to-face carrying out the transaction” (called “face-to-face collections” although obviously not “in front of you” but remotely, but in front of the payment process). For example, we move within this scenario when a traveler makes a reservation with online payment through your Booking Engine. This scenario is relatively simple to deal with, as in essence you will simply need to authenticate the payer in a reinforced way (3DS 2) if they are “affected” by the PSD2. Make sure you have the booking engine “ready for PSD2” with payment gateway adapted to the SCA.

The second is that of on-line payments where “the person paying is not present at the time of the transaction” (called “non-presential collections”). In other words, when the sale was made, the payer provided his card details, they were stored securely, and subsequently certain charges had to be made. For example, when we have to execute part of the charge for a reservation after it has been made, charge a no-show, extra fees, or a penalty for damage. This scenario is complex and requires knowledge and proper handling of the so-called “exceptions” to provide a precise solution to these situations so frequent in the management of our tourist accommodations.

 

Let’s review the different exceptions

Let’s learn when they will be necessary in the different cases that we find in the management of touristic rentals:

1. Payments made by Cards issued outside the European Economic Area EEA (+UK)

As long as the payer is not from the EEA + UK we have to know that the PSD2 does not affect him, then we can manage as before. We are not obliged by the SCA to authenticate on-line payments in a reinforced manner, and we can continue to deploy “non-presential” collections. It is important that your booking engine and payment platform is intelligent and can handle this exception automatically to avoid loss of conversion in your online sales.

 

2. Payments made by Anonymous Prepaid Cards or Corporate (called COR)

This exclusion would allow the typical B2B virtual cards used sometimes by Booking.com, Expedia, or certain agencies to be charged. As these cards are not nominal and are also used for “business-to-business” (B2B) payments, the regulations indicate that they can be transacted without enhanced authentication.

In another article, we will analyse how OTAs are being adapted to PSD2, but we have already told you that there will be a notable increase in the use of this “Virtual Card”. It is therefore essential that you have an adapted Channel Manager who can handle and charge these B2B cards properly, which are often limited to certain dates and charge amounts.

 

3. Merchant Initiated Transactions (MIT)

This is the exception that will take more prominence in the holiday rental, as it will allow us to channel the charges “from the rest of the reservation”, no-shows, extra fees, and many others.

These are operations initiated only by the commerce, where the payer is “absent” in the payment process. The first purchase or initial payment is made with SCA authentication and an agreement is created with the payer. In subsequent collections, the merchant can request to be charged again without the payer being present, because he has already given his permission to make future payments when the agreement is created (without a defined time or amount schedule).

There are different cases, very frequent in our usual management, in which a transaction can be considered MIT: payment of a reservation in different periods, increases in value, cancellation charges, no show… In general, these are cases in which the credentials (the authenticated card details) are stored with the traveller’s permission to make future payments but without a time schedule or defined amount.

In order for these transactions to be considered exceptions correctly, and carried out within the PSD2 regulations, there must be a prior agreement with the cardholder. If this agreement was made before the entry into force of PSD2 it will be valid. In the event that it is carried out later, a Strong Customer Authentication (SCA) must be carried out at the time of sale. Such authentication will be required so that the MIT transaction can be carried out in due course without the risk of being rejected by the issuing bank.

As we can see, the tourism sector has many typical use cases in which the correct implementation of the MIT exception is very important. For this reason it is vital to have a Booking Engine with a payment gateway adapted to PSD2, which not only handles the advance payment well at the time of booking, but also allows for the correct handling of any “non-presential payments” that may arise (payment of the rest of the booking, cancellation fee if applicable, charge of extra costs, deposit, etc).

It is also very important to have a Channel Manager who is adapted to the management that the different OTAs make of the payment data, and who knows how to manage the different exceptions in the right way in order to make it as easy as possible for you to launch transactions to collect your sales, penalties, no-shows, etc. From AvaiBook you have the best tools adapted to PSD2/SCA and the advice of experts in the field. 

 

 4. Transactions where payment has been initiated by phone or email (called MO-TO)

This is a still diffuse exception, to which many Property Managers and some software “cling” in an unorthodox way, and on whose limits there are still many unknowns. To be able to carry out a transaction with the exception of MOTO, and therefore without reinforced authentication, the sale has to be initiated “off-line”, and the moment of payment is channelled through a link to a payment gateway (which is understood to be on-line) or a card payment gateway.

The logic says that if, after sending a link by email to the payer, he is in a payment screen, then he would be in a “face-to-face payment” environment and by logic should be authenticated. On the other hand, a telephone payment gateway is not “tell me the card details and I will charge by hand at the POS”. This is a practice which is too widespread but insecure and which should not be carried out due to the high risk involved in not complying with the PCI, and risking fines and retrocessions.

At AvaiBook we are awaiting clarification on the use of this exception which, for example, would be appropriate for managing direct sales payments (you reflect the reservation in the system, and generate an email to the traveller to make payment or provide their card securely), but we will implement it in our PMS only if we have all the guarantees. Be wary of those who use this exception, because as we say “not everything is valid” as MOTO.

 

As you can see, PSD2 affects all the vacation rentals, but in AvaiBook you have the best tools adapted to PSD2/SCA to reduce the friction of your payments, besides the advice of our expert team in the matter.