Strong Customer Authentication (SCA)
What does the PSD2 require?
Payments a person initiates will require strong customer authentication. A process verifies whether the person using the payment method (e.g. credit card) is entitled to use the payment method. 3D Secure payments or Verified by Visa payments with a credit card are commonly known methods applying SCA. Electronic payments are, e.g. payments a customer triggers on a website. This also includes payments via an app or POS terminals. Excluded from the definition of electronic payment are (SEPA) direct debits, mail order bookings and telephone order bookings (MoTo payments). These regulations aim to reduce the risk of fraud in electronic payments.
What is strong customer authentication?
SCA identifies customers eligibility to use a payment instrument. Authentication is strong if personalised security features deliver proof. during payment. Currently applied features are:
- Ownership (e.g. the credit card and the printed CVC code itself, a mobile phone, a token (a physical device that generates one-time codes))
- Knowledge (e.g. PIN, password, card number)
- Personal characteristics of the user (e.g. fingerprint, iris (eye), speech/voice recognition)
As technical development progresses, this list of examples changes. The EU demands innovative technical solutions. Strong Customer Authentication must take place in digital payments whether you just process payment information or fulfil the payment itself.
What does this mean for you?
It all depends on the type of contract you have with your payment service provider that you use to process card payments (especially credit card payments).
If your contract is a so-called "eCom" (eCommerce) contract, you will have to apply the SCA (Strong Customer Authentication) in the future.
In the future, secure/strong customer authentication for electronic payments initiated by the customer (e.g. credit card entry on your website or in your app) will be required for transactions with this contract structure in the background.
Two of the above three features are required by the customer to perform authentication. This may mean, for example, that your customer must perform authentication using an app and additional password/PIN.
So-called "MoTo" (MailOrder-TelefonOrder) contracts are not seen as electronic payment transactions according to the current state of knowledge.
Payments made with this type of contract do not require secure/strong customer authentication.
However, due to the higher risk (because exactly this customer authentication is missing) MoTo contracts are usually designed with other/higher fees for the dealer.
At the time the customer agrees to an electronic payment (via a website or app), secure/strong customer authentication must be applied. Your contract with your payment service provider counts as an eCom contract clarifying this case to require action too. The following examples relate to cases in MIDOCO Midoffice.
Examples OTA
Online Intermediaries
1. You work as a travel agent and operate a website through which you arrange travel for various tour operators or service providers and are responsible for payment collection (agency debt collection). The client provides consent to the payment on the website immediately after the booking or already with the booking.
The customer wants to pay by credit card.
At this point, secure/strong customer authentication must in place.
=> SCA applies
2. You work as a travel agent, operate a website through which you arrange travel for various tour operators or service providers collecting payment (agency debt collection). The customer provides consent to payment on the website directly after the booking or already with the booking.
The customer wishes to pay by direct debit or invoice.
These payment methods do not count as electronic payment methods and therefore nothing changes compared to today's process.
=> SCA does NOT apply
3. You operate a website through which you mediate travel products for various tour operators or service providers collecting payment (agency debt collection). The customer provides consent to the payment on the website immediately after the booking or already with the booking.
The customer would like to pay by Sofortüberweisung.
Although Sofortüberweisung falls under the regulations of the Payment Services Directive 2, you as the intermediary do not come into contact with the customer's payment details. The customer authenticates himself as soon as he logs on to his bank in online banking to trigger the payment. So nothing will change for you compared to the process that already exists today.
=> Payment provider is responsible for SCA
4. You operate a website through which you mediate travel products for various tour operators or service providers. The Tour Operator collects the payment (direct debt collection). As an intermediary, you do not come into contact with the customer's money at any point.
Regardless of the payment method, you collect and forward the customer's payment information to the tour operator.
According to the information available to us today, the person who acts as an intermediary in the following payment transaction should also ensure authentication.
=> SCA applies
Examples Travel Agency
Retailing Offline
1. A customer walks into your travel agency and books a trip.
The customer pays the travel booking at your travel agency directly with his credit card via the payment terminal (POS terminal), which allows online payments - i.e. is connected online with the payment service provider.
The same applies to the remaining payment via the POS terminal.
=> SCA applies
2. A customer books a trip Agency collection is used. You do not use a POS terminal for payment.
The customer decides to pay by credit card and provides card details to you. You identify the cardholder (for example, by comparing credit card details with the customer's ID ).
This is not an "electronic payment" because the customer did not trigger the payment online (via app or website).
=> SCA does NOT apply
Examples Tour Operating
1. You are a tour operator and run your own website/app, where your customers can book a trip.
You also accept the payment of the customer who wants to pay with credit card
=> SCA applies
2. You are a tour operator and run your own website/app, where your customers can book a trip.
The customer decides to pay either by direct debit or by invoice.
These payment forms do not count as electronic payments.
=> SCA does NOT apply
3. You are a tour operator and run your own website/app, where your customers books a trip.
The customer chooses to pay via Paypal or Sofortüberweisung.
These payment forms are regarded as electronic payments, but the customer only triggers the payment per Sofortüberweisung, in his online banking or with PayPal. There your customer has to authenticate himself already today.
=> Payment provider is responsible for SCA
4. You are a tour operator and a travel agent sells a trip for you online (via his website or app). Direct/tour operator collection has been agreed with your agent.
The travel agent transmits the customer's payment data to you, which the customer enters on the website or in the agent's app.
In this case, the travel agency collects payment information an must inform you about this "online booking" transmitting the data.
=> SCA applies
5. You run a tour operator. A travel agent sells a trip for you at his local travel agency. You collect (direct debt collection) payment.
The customer decides to pay by credit card and presents it to the travel agent for payment.
The travel agent books in a booking tool entering the provided payment information after having identified payment eligibility of the customer for the credit card. In this case, the travel agency must inform you that the booking was "offline".
=> SCA does NOT apply
6. Your run a tour operator. A travel agent sells a trip from you online (via their website or app). Direct collection is agreed with your travel agent.
The customer wants to pay by direct debit or invoice.
The travel agent transmits the customer's payment data to you. This use case is identical to case 2. There are no additional requirements for you.
=> SCA does NOT apply
7. Your run a tour operator. A travel agent sells a trip from you online (via their website or app). Direct collection is agreed with your travel agent.
The customer decides to pay via Sofortüberweisung or PayPal.
This use case is identical to case 3. There are no additional requirements for you.
=> Payment provider is responsible for SCA
8. You run a tour operator. A travel agent sells your product. YOu agreed on Agency/travel agency debt collection.
The customer wants to pay by credit card.
Collecting and transmitting the customer's payment data to you, the travel agent is responsible for the strong authentication.
=>SCA applies
Glossary
Authentication
Ensure that the payment service user (customer) is the legitimate user (no payment amounts are involved yet).
Authorisation
Blocking of a concrete payment amount against the means of payment (used mostly for credit cards).
eCom
eCommerce - A common type of contract for internet transactions. This will require secure customer authentication for payment in the future.
MoTo
Mail Order/Telephone Order - A type of contract with a payment service provider that affects the requirements of secure customer authentication. Typically involves higher transaction fees than an eCom contract.
NFC
Near Field Communication (Contactless payment form, e.g. by credit card)
POS Terminal
Point Of Sale Devices that can be used to pay with a credit card or account card in a travel agency.
SCA
Secure Customer Authentication (Secure or strong authentication of the customer)
Contributors:
Magnus Kunhardt
Group Marketing Director
Steffen Faradi
CEO & Cofounder
Helmut Pilz
SVP Business Development
Here are some useful references to sites that report on PSD2:
http://www.bundesfinanzministerium.de/Content/DE/Gesetzestexte/Gesetze_Verordnungen/2017-07-21-G-z-Umsetzung-d-Zweiten-Zahlungsdiensterichtlinie.html
https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1533128025784&uri=CELEX:32018R0389
http://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+%28EBA-RTS-2017-02%29.pdf