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:

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

  2. MOTO transactions: Transactions initiated via mail or telephone orders.

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

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

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

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

  4. 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 blockTypeDescription
exemption.lowValueBooleanFlag as low value exemption
(Default - false)
exemption.transactionRiskAnalysisBooleanFlag as transaction risk analysis exemption
(Default - false)
exemption.trustedBeneficiaryBooleanFlag as trusted beneficiary exemption
(Default - false)
exemption.secureCorporatePaymentBooleanFlag as secure corporate payment exemption
(Default - false)
Note: Only applicable for Mastercard.
additionalInfo.challengeIndicatorString(2)“01” - No preference (Default)
”02” - No challenge requested
”03” - Challenge requested(3DS Requester Preference)
”04” - Challenge requested(Mandate)

Note: This is applicable only for merchants using Payvision's integrated 3DS Server
exemption.vmidString(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.merchantFraudRateNumberOnly applicable for MasterCard.

1 - Represents fraud rate equal or less than 1.
2 - Represents fraud rate between 1 and 6 including 6.
3 - Represents fraud rate between 6 and 13 including 13.
4 - Represents fraud rate between 13 and 25 including 25.
5 - Represents fraud rate greater than 25

Calculated as per PSD2 RTS (EEA card fraud divided by all EEA card volumes).

EEA
= European Economic Area
RTS = Regulatory Technical Standards
PSD2
= Payment Services Directive

Examples

ScenarioExemption blockchallengeIndicatorAction from Payvision
3DS 2.0 with Payvision's Integrated 3DS Server:
No exemption request
n/an/a.
By default this is 01 - No preference.
3DS 2.0 authentication followed by authorization processed without requesting exemption
3DS 2.0 with Payvision's integrated 3DS Server: Indicate Challenge preferencen/aFor example 02- No challenge requestedPayvision 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
: Request exemption
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 requestn/an/aPayvision processes the authorization without flagging exemptions
3DS 2.0 with an External 3DS Server - Authorization only: Request exemptionEg: exemption.lowValue = truen/aPayvision will apply the exemption flag when processing the authorization.
Non 3DS or 3DS 1.0n/an/aPayvision does not apply exemptions or challenge indicator when processing the transaction.

Updated 9 months ago

Strong Customer Authentication


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.


Top