Payment Authentication

Keywords such as PSD2, strong authentication or 3D Secure 2 have entered the world of online payments, especially as synonyms for fears of further problem-free card payments in e-shops and mobile applications. However, there is no need to be afraid of these topics as the ČSOB payment gateway handles most related activities on behalf of merchants. In addition, strong PSD2 authentication is reflected in card association rules allowing merchants to significantly increase transaction security as well as reduce fraud and unjustified complaints.

Why we authenticate online payments

According to the European Directive PSD2 (transposed into the Payment services act in the Czech Republic) all online payments are subject to the "strong customer authentication". “Strong” means the use of two authentication factors. Specifically, a combination of two of the three factors - something I know (such as a password), something I have (such as an activated mobile application or hardware code generator) and something I am (biometrics - typically a fingerprint or facial image).

Card payments are no exception. In practice, authentication using mobile applications has expanded beyond traditional online banking into the world of payments. These applications are either stand-alone (e.g. ČSOB Smart Key, George Key of Česká Spořitelna, etc.) or integrated in the mobile banking (e.g. Raiffeisenbank). Apple Pay and Google Pay wallets have an advantage over classic payment cards as Apple Pay and Google Pay perform customer authentication directly on the iPhone or Android - either by entering a system password (code) or by increasingly widespread biometrics (e.g. Touch ID, Face ID).

Authentication without customer's confirmation  

PSD2 regulation also enables authentication using a risk model that compares the current transaction with the customer's typical behaviour. 3D Secure 2 authentication works with this option. The payment gateway passes the data about the customer and the purchase to the card issuer. And it is exactly the card issuer who gradually - based on all the customer's payments - forms a model of the customer's typical behaviour. For each transaction, the card issuer then evaluates, based on additional purchase information, whether they accept the risks of the transaction - it is authenticated "in the background" and the customer does not have to confirm anything. Only if the transaction is, for example, for a large amount or the transaction deviates from the customer's typical behaviour, the card issuer will require confirmation. In such a case, the customer must confirm the transaction, for example, in the above mentioned mobile banking application. Of course, shopping and paying with background authentication is much more convenient because it is faster and there is no need for the customer to confirm in the card issuer's banking application. We, therefore, recommend sending as much additional purchase data as possible to the payment gateway so that the card issuer can make the best possible decision and does not unnecessarily require the customer's confirmation due to a lack of information about the transaction.

Providing additional purchase data for risk analysis at the card issuer  

Additional purchase data can be divided into several groups:

Data about the customer and his purchase history are important if the customer has a user account in the e-shop - data containing his account history (establishment, change, etc.) and the number of purchases are then transferred to the payment gateway.

Purchase data mainly contain the customer's contact details (billing and delivery address). The data do not contain individual shopping cart items. Purchase data contain information about the nature of the purchase (whether it is goods, services, digitally delivered content, etc.) and risky items (such as credit gift cards).

Customer device data - during the payment, the card issuer obtains a technical parameters fingerprint of the customer's browser or smartphone. If a customer purchases from the same device as before, they are more likely to authenticate in the background without confirmation.

The context of privacy and GDPR

In terms of personal data protection and GDPR, the bank and the merchant act as independent personal data controllers and thus fulfil their legal obligations to each other. In particular, we would like to draw attention to the obligation to transparently inform customers about what data is being processed and for what purpose. The bank fulfils its obligation to its clients by publishing the document “Information on the processing of personal data” on its website. We regularly update this document, including adjustments related to the implementation of 3D Secure 2. Similarly, the merchant should inform their customers. The data structure used by the payment gateway API to transmit additional purchase data can be found in detailed description.

Exemption from strong customer authentication for small amounts of payments  

For transactions below CZK 700, it is possible to ask the card issuer not to authenticate the transaction. The goal is to speed up a payment that involves little risk for the merchant (for example, based on his knowledge of the customer's behaviour). If the card issuer accepts the request, the transaction is authorised without authentication. If the request is not accepted by the card issuer (e.g. due to exceeding the permitted number of consecutive transactions without authentication), then the card issuer will request authentication with confirmation by the customer.

If you want to use the low-value payment exemption, please contact [email protected]. This service is not activated automatically. When using this exemption, the risks of the transaction are taken over by the merchant, who is not protected against the complaint of the transaction by the customer. Therefore, the payment gateway does not apply the low-value payment exemption to each transaction automatically and the merchant requests it at its discretion when initialising the transaction using the API function payment/init or using the API function oneclick/init.

The low-value payment exemption is only available for regular card payments or for OneClick payments - it cannot be applied to Apple Pay and Google Pay wallets.