Overview of PSD2 and strong customer authentication
PSD2 overview
PSD2 is an extensive revision of the Payment Services Directive regulations for the European Economic Area and the United Kingdom. It took effect on:
- March 14, 2022 for the United Kingdom.
- December 31, 2020 for the rest of the European Economic Area.
Objectives
The objectives of the PSD2 legislation include:
- Standardize regulations and integrate the market for payment services in the European Economic Area and the United Kingdom.
- Ensure fair competition and transparency.
- Open payment services ecosystem and reduces bank monopoly on their customer’s data. It will allow third-party service providers to retrieve customers' account data from the bank with account holders' consent.
Scope
PSD2 applies to the online transactions where both the issuing and acquiring banks are located within the European Economic Area and the United Kingdom. See the latest update in this Community post for more information.
Strong customer authentication
Strong customer authentication (SCA) is one of the mandates of PSD2 that is most applicable to Zuora customers in the European Economic Area and the United Kingdom. SCA requires that merchants use two-factor authentication to reduce the risk of fraudulent transactions. As a growing number of transactions take place online, especially on mobile devices, SCA will help to make it easier for customers to pay and reduce the risk and cost of payments fraud.
With SCA, all electronic transactions will need authentication using at least two of three possible methods:
Benefits of SCA
SCA can introduce the following direct and potential benefits to your business:
- Reduce the risk of fraudulent transactions.
- Lower the chargeback rate because of the increased authorization approvals.
- Lower the customer churn rate by providing a secure environment with minimal impact on customer experience.
- Increase customers' confidence in online transactions.
SCA exemptions
SCA is made a requirement for all online transactions by PSD2. However, some exemptions are applicable to a given payment attempt, which means end customers may not need to provide additional authentication for their transactions.
Typical exemption use cases include:
Low-risk transactions
After carrying out transaction risk analysis (TRA), the acquirer or issuer decides that the transaction does not need to be challenged. TRA may be applied to transactions up to €500.
Low-value transactions
The exemption applies if the transaction value is less than €30. But the issuer must keep track of the accumulated amount and the number of transactions. The issuing bank must overrule the exemption once a card exceeds a certain threshold.
Recurring payments
The SCA exemption applies to a series of transactions of the same amount made to the same business. SCA will be required for the customer's first payment, and the subsequent charges may be exempted.
Trusted beneficiaries
Cardholders have the option to whitelist merchants as a “trusted beneficiary” when completing authentication for a payment. The issuer or payment service provider will not require strong customer authentication on subsequent payments for the same merchant. This exemption depends on if the issuing bank has adopted the whitelisting feature.
Merchant-initiated transactions
Merchant-initiated transactions (MITs) are the transactions that are initiated using the previously stored card information when the cardholder is not present. Technically, MITs are out of the scope of SCA. However, submitting an MIT is considered to be requesting an SCA exemption in practice. Like other transaction, it is still the bank who should determine whether authentication is needed.
Whether SCA challenges will be placed is determined by issuing banks instead of Zuora or Zuora's gateway partners. Zuora's integrations with gateway partners seek SCA exemptions when configured appropriately. However, some issuing banks in Europe have incorrectly issued challenges to users even when the configuration has requested exemptions. Under these circumstances, reach out to your gateway provider who will directly interact with issuing banks to help resolve ongoing issues.
Using 3DS2 for SCA compliance
A new standard called 3DS2 (3D Secure 2.0) is now being promoted as a solution for SCA under PSD2. 3DS stands for 3D Secure, an open standard used by major credit card brands to authenticate cardholders. 3DS can dramatically reduce fraud and increase authorization approvals and is one of the primary ways for Payment Services Providers to comply with the SCA mandate.
3DS2 requires merchants to send additional data with each transaction so that the bank can validate if the transactor is the actual cardholder. If the data matches what the bank requires, the transaction will continue as a frictionless flow and no further user input is required.
The following table describes the difference between 3DS and 3DS v2 and why it is important:
3DS (3DS v1) | 3DS2 (3DS v2) | Why is it important? |
---|---|---|
For payment cards only | Also supports mobile and digital wallets | Greater flexibility and support for mobile e-commerce. |
Designed for web desktop |
Streamlined for mobile interaction models/devices | 3DS2 adoption expected to be greater because it is easier to use. |
Higher false declines |
Modified authentication flow and reduced false declines |
Customers are more likely to abandon a transaction or use a different payment method. |
No merchant opt-out or exceptions | Lower-value transactions exempted from validation, depending on the merchant's fraud rate | Greater flexibility and alignment of the protocol to the risk of a particular transaction. |
10 data points captured | Up to 150 data points captured |
The issuer can make better decisions about the validity of the transaction with more data, preventing both fraudulent transactions as well as false positives. |
Zuora's support for PSD2
Zuora integrates with different payment gateways and processors, and provides PCI compliant hosted Payment Pages. For more information, see Zuora’s implementation of 3D Secure 2.0.