Information for Computop customers on the integration of 3D Secure 2

Merchants offering online credit card payments in the European Economic Area must support the 3D Secure 2 protocol by October 16, 2020 at the latest. On the following page, you will find all relevant information on the timely and proper migration.

What merchants should be aware of:

By when must the migration be completed?

Your acquirer is obliged by the card companies to ensure that you as a merchant are technically capable of transferring credit card payments via the 3D Secure 2 protocol (version 2.2 or higher) by the cut-off date of 16.10.2020.

For you this means that you must have completed the following processes by 16.10.2020:

  •  Adaptation of the necessary transaction parameters for transmission to Computop Paygate.
  •  Successful testing of the data transfer to our interface.
  •  Successful transmission of test transactions to your acquirer.

Not acting is not an option!

The introduction of the 3D Secure 2 protocol within the European Economic Area is a binding requirement of the credit card companies.

As a payment service provider, we cannot influence deadlines and the entire rollout procedure. It is certain that very soon credit card transactions that are not processed via 3D Secure 2 will be rejected for further processing by your acquirer and the card companies.

For this reason, we would like to encourage you in your best interest to take all the necessary steps by autumn 2020. Otherwise, you will not be able to offer credit card payments in your online shop to customers from the European Economic Area from 2021 on.

Required steps for the 3D Secure 2 integration:

1. Adaptation of the necessary transaction parameters

Please adjust the extent of the transaction data transmission according to our online documentation. Please note our recommendations for the selection of additional data fields whose transfer enables the issuer to carry out an optimal transaction risk analysis which optimizes your conversions.

2. Setting up a test MID

To test the correct data transmission to Computop Paygate you must set up a test MID. If you have received your own test MID (you can recognize it by the fact that the name contains "test"), use it to transfer test transactions.

Otherwise, you will find the generally valid Computop test MID for 3D Secure 2 in your Computop Analytics account. Optionally you can also apply for a new, individual test MID from our Merchant Services team.

3. Sending a test transaction to Computop Paygate

Now send a transaction to Computop Paygate using the test-MID. If your adjustments to the 3DS protocol are correct you will receive a confirmation of success for your test transaction.

4. Carrying out the acquirer test

With the confirmation of success please contact [email protected]. Our team will contact you immediately to test the further transfer of your payments to your acquirer(s).

If you receive an error message on your test transaction, please check your customization again based on our online documentation. Our Merchant Services team will be happy to help you with any problems.

 

Frequently asked questions (FAQ) for technicians and integrators

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.

In this regard, we recommend that you contact your acquirer directly. Please also check whether your current contract with Computop includes provision of the 3D Secure protocol.

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 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.

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 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.

Frequently asked questions (FAQ) for e-commerce managers and decision makers

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

  1. 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),
  2. the payments do not exceed the corresponding thresholds, and
  3. 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, 3DS 2 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 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.

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.

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 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 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.

By 16.10.2020 you must first prove to your acquirer that payments in your online shop can be processed using the 3DS 2.2 protocol. It is expected that from the beginning of 2021 all online credit card transactions will be rejected by acquirers that were not submitted via 3DS 2.2 or a higher version.

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.

Glossary

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.”

If you have any questions, please contact our support.

For an initial contact, please use the besides standing form or call us: +1-800-701-7806

(* Mandatory fields)