Strong Customer Authentication
The Revised Payment System Directive (PSD2) is a European Economic Area (EEA) regulation which includes a mandate for Strong Customer Authentication (SCA) . It aims to make online payments more secure and increase authorization rates while reducing electronic payment fraud.
Payvision offers a 3D Secure 2.0 solution to merchants that provides full PSD2 and card scheme compliance, combined with flexibility and ease of integration. Read more
What is SCA?
As the name suggests, Strong Customer Authentication is a way to reduce fraud by verifying that the customer is exactly who they claim to be, before authorizing their payment. In order to achieve this, two-factor authentication will be required.
Two-factor authentication is a combination of knowledge (e.g. password), possession (e.g. cell phone) and inherence (e.g. biometrics). In other words, this includes two of three options -- such as a password you know, a token on a device you own, and something that identifies you, like your fingerprint.
Scope of SCA
The SCA mandate applies for all intra-EEA payer-initiated transactions where both the issuing and acquiring banks are located in the EEA region, apart from a few narrowly-defined exemptions which can be requested.
Certain types of transactions are out of scope of PSD2, meaning that neither SCA nor an exemption will be required.
For an EEA-based merchant, the SCA requirement does not apply for:
-
Merchant-initiated transactions: These are transactions initiated by the merchant once an explicit agreement (mandate) is drawn up between the merchant and customer regarding the frequency of the merchant initiated transactions. Note that this covers the use cases of recurring, merchant-initiated and Unscheduled Credential on File (UCOF) transactions. In this instance, SCA is only required when setting up the mandate.
-
MOTO transactions: Transactions initiated via mail or telephone orders.
-
One leg out transactions: Inter-regional transactions where either the issuer or acquirer are outside the EEA.
PSD2 SCA Exemptions
For transactions that are in the scope of PSD2, a merchant can request that the SCA requirement be ‘exempted’ in certain scenarios. The issuer decides if the exemption is granted or not.
The available exemption scenarios include:
-
Low-value transaction: Transactions lower than EUR 30 in value qualify as “low value” transactions and can be exempted from SCA. There is a caveat in this scenario, however. According to PSD2 guidelines, SCA must be applied after either a maximum of 5 non-SCA low-value transactions are done on the card OR a cumulative amount of 100 EUR has been authorized on the card without SCA. This makes the situation a little tricky because the merchant doesn't have an overview of how many transactions have occurred on the card, or whether the cumulative amount of EUR 100 has been reached.
-
Transaction Risk Analysis (TRA) Exemption: This is a scenario where an acquirer (or issuer) can request an exemption from SCA based on a comparison of the institution’s fraud rates and the transaction value.
-
Whitelisted merchant transactions: Also known as the “trusted beneficiary”, or the "whitelisting" exemption. For this exemption, the cardholder would have to indicate to their issuer bank that a particular merchant can be trusted. Transactions performed at this merchant can be exempt from SCA.
-
Secure corporate payments: Payments made through dedicated corporate processes initiated by businesses and not available for consumers. (e.g. lodge cards, central travel accounts and virtual cards)
3D Secure 2.0, Exemptions and Liability
From a risk management perspective, merchants need to consider a combination of factors that could affect their existing business processes.
-
PSD2 SCA compliance is necessary for EEA-based merchants. After the compliance deadline, issuers in the EEA region will be forced to soft decline in-scope transactions where the cardholder has not been authenticated with two-factor authentication, and an applicable exemption has not been requested.
-
The fact that final decisions on exemptions are made by the issuer means that merchants will now have to implement 3DS2, along with the possibility of an exemption mechanism if they want to skip the authentication challenge for a more frictionless flow.
-
For intra-EEA transactions, if the merchant requests SCA exemptions and the issuer grants it for a frictionless flow, the merchant is liable in case of chargebacks.
In conclusion...
The merchant will need to evaluate their risk appetite for possible chargeback fraud losses to decide whether an exemption should be requested or not.
From a compliance and liability perspective, the safest option would be to authenticate a cardholder via 3D Secure 2.0 without any exemption requests
How do you flag SCA exemptions?
Payvision supports the possibility to request SCA exemptions and indicate the challenge preference when submitting the Payment, Checkout or Payment link request (depending on the integration option).
This can be done with the following threeDSecure block fields in the API request.
Field in threeDSecure block | Type | Description |
---|---|---|
exemption.lowValue | Boolean | Flag as low value exemption |
exemption.transactionRiskAnalysis | Boolean | Flag as transaction risk analysis exemption |
exemption.trustedBeneficiary | Boolean | Flag as trusted beneficiary exemption |
exemption.secureCorporate | Boolean | Flag as secure corporate payment exemption |
exemption.vmid | String(8) | Visa Merchant Identifier – Required in case the TrustedBeneficiary Exemption is being applied with Visa Secure Note: This is applicable only for merchants using an external 3DS Server. |
additionalInfo.challengeIndicator | String(2) | “01” - No preference (Default) Note: This is applicable only for merchants using Payvision's integrated 3DS Server |
additionalInfo.merchantFraudRate | Number | Only applicable for MasterCard. 1 - Represents fraud rate equal or less than 1. Calculated as per PSD2 RTS (EEA* card fraud divided by all EEA card volumes). EEA = European Economic Area |
Examples
Scenario | Exemption block | challengeIndicator | Action from Payvision |
---|---|---|---|
3DS 2.0 with Payvision's Integrated 3DS Server: | n/a | n/a. | 3DS 2.0 authentication followed by authorization processed without requesting exemption |
3DS 2.0 with Payvision's integrated 3DS Server: Indicate Challenge preference | n/a | For example 02- No challenge requested | Payvision will relay the challenge preference to the issuer in the authentication request. However, it is up to the issuer to decide if the cardholder gets a challenge or not. |
3DS 2.0 with Payvision's integrated 3DS Server | Eg: exemption.trustedBeneficiary = true. | n/a. (the challenge preference is derived from exemption flag in this case) | Payvision will apply and request for the specified exemption in the authentication request. If granted by the issuer, Payvision will apply the same in the authorization request. |
3DS 2.0 with an External 3DS Server - Authorization only: No exemption request | n/a | n/a | Payvision processes the authorization without flagging exemptions |
3DS 2.0 with an External 3DS Server - Authorization only: Request exemption | Eg: exemption.lowValue = true | n/a | Payvision will apply the exemption flag when processing the authorization. |
Non 3DS or 3DS 1.0 | n/a | n/a | Payvision does not apply exemptions or challenge indicator when processing the transaction. |
Updated about 1 year ago