How does 3D Secure work so far?
The globally standardized 3D Secure Protocol (3DS), which was introduced in 2002, offers merchants and consumers additional security for credit card transactions. With this procedure, online shoppers verify themselves to their card-issuing bank (issuer) as legitimate cardholders. In contrast to a conventional credit card payment process on the Internet, 3D Secure requires an additional security code. This makes the misuse of credit cards much more difficult.
How does 3D Secure 2.0 differ from the previous method?
Essentially, 3D Secure 2.0 is a refinement of the previous 3D Secure protocol. With each credit card order, up to 100 data points will be be transmitted to the issuer; based on these data points, the issuer performs a real-time risk assessment. If a transaction is classified as low-risk, it can be authorized directly and without further interaction by the buyer. However, if fraud is suspected, the buyer is requested to confirm his identity again, for example by push-TAN. The risk assessment takes place in the background and is not perceptible to the buyer. The collection and forwarding of the necessary data takes place both via the merchant's shop backend and via the Payment Service Provider (PSP), which connects 3D Secure 2.0 to the respective shop.
When and why will 3D Secure 2.0 be introduced?
The declared aim of introducing 3D Secure 2.0 is to meet the requirements of Strong Customer Authentication (SCA) and to establish it as the standard for electronic payment procedures from 14 September 2019. On the other hand, the introduction is also intended to reduce the percentage of cancelled purchases: Thanks to the individual, data-based risk assessment, transactions can be cleared directly and without further buyer interaction in approx. 95 percent of all cases - in future, the majority of purchases will therefore take place without entering a 3D Secure Code.
New about PSD II / 3D Secure
Improving usability for the 3D Secure 2.0 process - delegation of SCA
Yes. Independent of the Integration type (Forms, Server-to-Server, Hosted Payment Page) and if you have previously used 3D-Secure or not, changes to your Paygate integration will be required.
The least effort occurs by using Computop forms or PayNow.
We recommend to contact your acquirer to discuss necessary changes.
Even though a Transaction may have a low value it may instigate 3DS. The issuer tracks initiated transactions and saves the amount. Above a certain amount it may automatically initiate the authentication challenge.
The effort is relatively low because merchants only require a few additional data sets while calling the card form. The process stays the same. Of course, the merchant receives more data within the Paygate response. However, these are not relevant for subsequent payment actions and therefore, the merchant can decide to either save the authentication data for internal purposes or not.
Most likely not all banks will have migrated to Version 2.0 yet by September 14th, 2019. Therefore, you will require to offer both versions to support all customers Independent of their card issuer. If you use Computop forms you are automatically compliant to both versions.
VISA, MasterCard, American Express, Diners/Discover, JCB as well as China Union Pay (CUP).
No, you as a merchant do not have to distinguish between the brands.
Computop consolidates all relevant differences that occur between Paygate and the Scheme Directory Servers.
Customers can whitelist selected merchants at their bank. This increases the probability for the customer to benefit from frictionless authentication. However, a customer may still be challenged in specific cases (e.g. in case of a high basket volume).
No. Computop will maintain the existing parameter "RTF". For new implementations we have added the Parameter "credentialOnFile" as a structured JSON object to map the relevant logic. Both will be supported in the future.
This Kind of payment requires a flagging as Customer Initiated Transaction.
No. The capture mode is irrelevant to 3D-Secure.
No. The issuer holds the liability.
No. The liability shift stays valid.
Due to the new requirements of 3D-Secure the number of digits has increased within the payment string. For this reason, we highly recommend to use the call method POST to avoid errors.
You can continue using the feature without any amendments. The new 3D Secure 2.0 parameters are still required. Please also note our COF flows (XSLX file).
To date we only implemented Acquirer Exemptions and Whitelisting via private extensions for MasterCard.
The whitelist is maintained at the sole discretion of the issuer and cardholder. Computop Paygate will receive whitelist information through its 3DS server that participates in the 3DS authentication flow.
The Payment Services Directive II was passed in October 2015 and is a regulation on payment services and payment service providers, which was adopted by the European Commission as an EU Directive. It is an advancement of the first PSD and accordingly applies throughout the European Union and the European Economic Area. It aims to increase security and transparency in payments, to lower entry barriers for payment services and to provide the basis for fair competition.
The EU Directive concerns both the payment industry and the consumer. For the payment industry, it establishes clear rules designed to strengthen competition within the European financial industry by improving the position of payment service providers. It ends the monopoly of banks on account information and allows third party providers (TPPs) to give customers access to their own account information. In addition, it creates the prerequisites that allow TPPs to trigger payment transactions directly without a bank being involved in the transaction.
Two new kinds of TPPs are regulated in PSD II: The Payment Initiation Service Provider (PISP) and the Account Information Service Provider (AISP). To enable these providers to do their work, banks must open their APIs (Application Programming Interfaces) to those who request them and are regulated according to the rules.
For consumers and merchants, the security of transactions will be increased by a mandatory strong authentication (Strong Customer Authentication/SCA), which requires a two-factor authentication (2FA) for e-commerce transactions. Hence, the rules for card payments and fraud prevention will become stricter.
PSD II covers all payment procedures for remote electronic payments.
The SCA (Strong Customer Authentication)/two-factor authentication (2FA) requirement is part of the PSD II payment directive. SCA comes into effect whenever a user wishes to initiate an electronic payment. In order for a customer authentication to be successful, at least two of the three factors of knowledge, inherence and possession are required. SCA is used only for e-commerce payments initiated by customers. If the user can submit the information correctly, the payment is approved.
The knowledge factor is covered by a password or PIN only known to the account holder or card holder.
Among others, a possession factor can be the user's smartphone. The user must prove his ownership via a verification message within an app on the smartphone. In practice, this approach applies, for example, in banking apps. The bank queries a TAN, which is generated and displayed directly in the banking app. Although this is a so-called one-time password (OTP), the decisive factor in this process is the mobile device to which it is sent: An individual possession of the user.
According to PSD2, SMS-TANs are no longer permitted. PSD2 stipulates that banks must maintain control over channels. This requirement is not guaranteed for TANs sent via SMS. TANs generated in TAN apps, on the other hand, meet the standards.
The inherence factor is covered by biometric data. For example, the user authenticates himself on his smartphone with a fingerprint, face or iris scan.
SCA is mandatory both for the initiation of electronic payments and for the access to applications that trigger electronic payments and/or provide access to account information. A distinction according to form of trade or distribution channel is not provided for. The extent to which a payment method is subject to SCA depends on whether a card payment is involved or whether the consumer has the option to execute or revoke the payment upon receipt of the goods.
B2B payments are subject to SCA in the same way as B2C payments. However, there is one exception: SCA does not apply for B2B payments if they are executed in a process typically used only by companies, which is not based on the authentication of an individual and if an authority has confirmed that the security standards comply with the requirements of PSD II.
The services which execute the payment initiation or authenticate the customer are responsible for the implementation. These are usually the providers of the payment methods or their acquirers. They are required to provide the SCA process.
Merchants are only legally responsible if they trigger the payment themselves, for example via an interface to the banks. They must then ensure that the Bank's actions regarding SCA are integrated into the process.
The PSP does not account for the SCA. It should be noted that the single providers of payment methods are responsible for the provision of the SCA process. Only for direct debits the merchant or payment service provider could carry out a SCA themselves, but it is not currently required for direct debits. Another special case is Instant Payments. Here, the PSP or the merchant would be the payment initiator and would have to execute the authentication procedures of the customer bank via an interface. Furthermore, they would need to be regulated as a payment initiation service.
It should be pointed out that the merchant has no choice of whether to apply SCA or not. It is a mandatory requirement in electronic payment transactions. The merchant merely integrates the SCA process. However, from a technical point of view, the query never takes place on the merchant's website, but is only integrated there via an iframe.
The storage of the authentication data depends on the method used. If In-App-TAN is used, no storage takes place, since the TANs are generated individually for each transmission. Biometric data is only stored in the owner's device in a protected environment. There is no transmission of biometric data whatsoever. The authentication is executed by the analysis of a hash value which cannot be deciphered by unauthorized parties. As before, PIN and passwords are stored on protected servers of payment service providers. Only PCI-certified companies are entitled to store sensitive data such as card numbers which is why many merchants rely on payment service providers such as Computop. Merchants do not need to store the original numbers in their systems and are only in the possession of pseudo card numbers, which prevent a fraudulent transaction in case of data loss. Also, further transaction data will be only stored on secure servers of PSPs and banks.
The type of identification depends on the selected payment method provider. Apple Pay, for example, authenticates online purchases via a connected iPhone with biometric recognition. Online bank transfer methods often use a TAN from a protected mobile app. If the online purchase is made on a mobile device of a proven owner, a PIN or password are still possible as a second factor.
Dynamic linking is carried out by the customer's account-holding bank. The payment data is subsequently transmitted to the customer during authentication.
Trusted beneficiaries can be identified by the customer within his online banking portal if the bank offers this service. For this purpose, he creates a list of trustworthy merchants, the so-called whitelist. This process ensures that transactions made to the listed merchants are not strongly authenticated. In this case, SCA only needs to take place initially to confirm the created whitelist or the respective trusted beneficiary. All subsequent transactions to the merchant are realized without SCA, as long as the transactions do not have any general anomalies.
Small amounts for remote payments of up to 30 EUR are exempt from SCA as long as the total volume of transactions since the last SCA has not exceeded 100 EUR or more than five payments made without a SCA check. The general prerequisite for this exception is that the transaction does not have any obvious risk characteristics, such as a blocked card number.
In the case of recurring payments, the payment is initiated by the merchant; this is known as MIT (Merchant Initiated Transactions). According to EBA (European Banking Authority), these are exempt from SCA if the first transaction of the subscription has been authenticated according to SCA.
This regulation on recurring payments also includes deviations in payment amounts or dates, as long as these are within a range to expected by the customer. A payment initiation with Card on File (COF), in which the merchant displays an existing card number to the customer, which the customer only confirms, is still in scope of SCA, as the customer is the final payment initiator.
Agreements on recurring payments that were made before the PSD II became effective are not affected and do not require any subsequent strong authentication.
According to Paragraph 18 and 19 of the RTS, the issuer may waive SCA if
- the fraud rate for the corresponding type of payment (card or credit transfer) does not exceed certain values calculated for the entire payment service provider (table),
- the payments do not exceed the corresponding thresholds, and
- no unusual scenarios such as deviating payment behaviour or high risk locations are identified.
MOTO transactions are not considered as electronic transactions in the PSD II and are therefore not subject to SCA obligations.
The PSD II requires SCA in many cases. 3D Secure (3DS) meets the requirements of SCA. Credit card companies such as VISA, Mastercard, American Express and JCB use the technology to prevent misuse of credit card data. For the merchant, the risk of fraud and possible payment defaults is reduced. Whoever uses 3D Secure as a merchant receives a guaranteed receipt of payment, because if the transaction is approved despite a 3DS query and still turns out to be fraudulent, the issuing bank of the credit card (issuer bank) is liable for the damage.
Compared to 3D Secure 1.0, 3DS 2.0 includes various enhancements that make the purchasing process easier for customers and merchants. Like in the previous procedure, online shoppers identify themselves to their issuer bank as legitimate cardholders via 3D Secure. In version 2.0 however, the originally static query of a security code is replaced by a real-time risk analysis. With each credit card order, up to 100 data points and thus up to 10 times more information are transferred to the issuer bank. The collection and forwarding of the data both takes place via the shop backend of the dealer and via the PSP itself. The data transfer takes place in the secure environment of the 3D Secure Server. When the issuer's subsequent real-time risk assessment lowers the risk, the transaction is approved. If there is an increased risk of fraud, the consumer must confirm his identity.
Neither the responsible industry association EMVCo nor the credit card companies set a binding deadline for the integration of the new standard into online shops. 3DS 2.0 itself is not a legally binding standard. The decisive question for the merchant is whether a procedure for processing credit card transactions can be provided in his own online shop by 14 September 2019, which meets the requirements of the SCA. 3D Secure 1.0 is also permitted as a minimum solution.
For Amazon's Echo, voice recognition payments are enabled by default. Amazon currently solves the problem of confirmation via an optional four-digit code. The user either has to recite this code before every purchase or (in case he registers his voice with Alexa) he only has to recite it initially and then can buy barrier-free via his voice.
Voice shopping via Google Home has so far only been activated in the USA. To enable payments, the user must activate the payment function in the Google Home app on the smartphone or tablet, set the payment method, and then manually select the Google Home devices in the app that are eligible to make purchases.
Google also allows the user an optional confirmation of purchases via fingerprint recognition on the mobile device or entering the password of the Google account on the mobile device.
Without 3D Secure, a payment generally will be rejected. However, version 3DS 1.0 is still sufficient as a minimum solution.
A customer cannot put himself on the list of trustworthy recipients, however, he can declare merchants as trustworthy. A general exemption for all merchants is not possible, the merchants must be named individually. In addition, his bank may continue to carry out the 3DS in individual cases if it has indications of an increased risk of the corresponding transaction. In addition, banks are generally not obliged to maintain a whitelist.
According to the new PSD II directive, PayPal will no longer function via a pure password login in the future. The switch to two-factor authentication, which PayPal already offers as a voluntary solution, will become mandatory when PSD II becomes effective. It is the responsibility of PayPal.
The following data is collected by the merchant’s Payment Service Provider (PSP), processed, and then transferred to the 3D Secure server:
- Credit card data that must be collected and processed in accordance with PCI DSS requirements.
- Transaction-related data this includes the identification numbers required to match the transaction and the merchant, as well as the amount and currency of the purchase.
- Browser information that provides information about the device used and the location of the user. This includes the IP address, screen height and width, as well as the browser language used.
The following data is collected in the merchant’s shop system and transferred to the 3D Secure server via the payment interface of the PSP:
- Billing and shipping address: The complete billing and shipping address for the order.
- Customer account: Data that was collected in association with an existing customer account. This includes information on the length of time that a customer‘s account has been open, the number of transactions carried out within certain time intervals, and the frequency of changes of passwords and shipping addresses.
- Delivery details, such as the shipping method selected, availability of the goods, the delivery window, the e-mail address for the delivery of digital goods, or the date of first availability for products not yet released
No. EMVCo (credit card industry association), the organization responsible for the definition of the 3DS 2.0 standard, distinguishes between mandatory and optional data points and data. The latter includes all data collected from the merchant backend during the ordering process.
However, to make the best use of the new 3DS 2.0 process, the collection and transfer of all parameters is strongly recommended. The more data that is included in the issuer’s transaction analysis, the more accurate the assessment of the fraud probability of a transaction will be.
The crucial question for merchants is whether a procedure for processing credit card transactions that meets the requirements for strong customer authentication (SCA) can be provided for their online shops by September 14, 2019.
The existing 3DS 1.0 process is available as a “minimal solution”. It basically fulfills the requirements of SCA, but contains numerous, unclear exceptions under which the 3DS code does not necessarily have to be requested. If merchants continue to use 3DS 1.0, they will be at risk of violating strong customer authentication if they apply the exceptions incorrectly. By contrast, the 3DS 2.0 process developed in consultation with the European Banking Authority (EBA) is SCA-compliant in every respect, according to EMVCo.
Merchants who use the previous 3DS procedure will not be able to avoid an "upgrade" to 3DS 2.0 in the near future. Basically, the motto should apply here: The sooner the better, since a timely decomissioning of the old protocol has been announced. However, the 3DS 1.0 procedure will presumably be accepted by most issuer banks as a fallback option for an indefinite period even after September 2019.
Merchants who want to implement the 3DS 2.0 process in their online shop must:
- Check with their payment service provider to determine whether they support the 3DS 2.0 protocol
- Modify the forms involved in the order and checkout process in coordination with the payment service provider to provide the required customer data for transmission
- Integrate the 3DS 2.0 protocol in their mobile shopping apps (if available) in addition to the online shop
- Register the supported 3D Secure 2.0 process with their acquirer
The good news for our customers: We can handle most of the required work for you. As with all our products, the appeal of our 3DS 2.0 solution is that we keep implementation as simple as possible for our customers.
The whitelist is maintained at the sole discretion of the issuer and cardholder. Computop Paygate will receive whitelist information from the Issuer through its 3DS server that participates in the 3DS authentication flow.
The transitional period requires certain conditions. First of all, it is up to the national supervisory authorities to agree. BaFin has made it clear that it agrees with the EBA's view. However, the prerequisite for this is the existence of an explicit migration plan for the switch to strong customer authentication, which contains clearly defined intermediate goals. Traders should continue to use the conversion date 14.9. A late readiness for SCA still means that it is not in conformity with the law and carries the risk of a higher rejection rate.
The EBA has clarified that 3DS 1.0 is not adapted to all requirements of PSD2. Specifically, this statement related to the ability for traders to make use of certain exceptions that exempt the PSD2 requirements. At the same time, retrieving a password in e-commerce will still be considered an element of knowledge, so we believe that using a password query for authentication to 3DS 1.0 will continue to be supported, provided the password is sent PSD2 compliant. Nevertheless, we recommend that you only use 3DS 1.0 as a fallback solution, since in any case the challenge, ie the presentation of the password query, will occur and the missing exceptions will lead to a lower conversion rate in the checkout. In addition, the card brands have already indicated that the 3DS 1.0 protocol will be taken off the market in the medium term.
Corporate payment transactions can be exempted from SCA if the conditions according to Article 17 - Secure corporate payment processes and protocols are met. An exemption requires “dedicated payment processes or protocols that are only made available to payers who are not consumers”.
In this context, the term Merchant Fraud Rate is not to be confused with the fraud rate for a particular merchant. The Merchant Fraud Rate in the context of EMV 3DS relates to articles 18 and 19 of the Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA) published by the European Banking Authority (EBA).
Article 18 - Transaction risk analysis describes the conditions that must be met to apply exemption from SCA based on low risk levels associated with particular transactions. One of these conditions is the relevant exemption threshold value (ETV) and the referenced fraud rate as described in Article 19 - Calculation of fraud rates. Acquirers (PSPs in EBA terminology) may register with their local authorities for exemptions to SCA based on their low fraud rates calculated across their entire ecommerce merchant portfolio.
MasterCard established a workaround via private data in the message extension data field of the authentication message to communicate the acquirer fraud rates to the issuer when requesting an exemption based on article 18.
If one of the participants, either the payer’s payment provider (i.e. issuer) or the payee’s payment provider (i.e. acquirer) is located outside of the EEA (European Economic Area), the transaction is not in scope of the PSD 2 and thus SCA does not apply. The EBA states that in such situations “the European PSPs shall make every reasonable effort to determine the legitimate use of the payment instrument.”