Strong Customer Authentication (SCA)
The second version of the European Payment Service Directive, or PSD2 for short, demands a strong customer authentication (SCA) for all card-not-present transactions to protect the cardholder and businesses from the financial losses that could arise due to a fraudulent transaction.
3-D Secure version 2.x.x is the most common authentication protocol where the cardholder must prove the ownership of the card by authenticating with at least two out of the following three methods:
Something they know (i.e., a PIN or password)
Something they possess (i.e., a card reader or mobile device)
Something they are (i.e., voice recognition or fingerprint).
EMV 3DS version is being upgraded continuously to meet the evolving digital payment needs and so the card schemes. Worldline recommends you to use the latest version of 3DS supported by Worldline to stay compliant.
Out-of-scope transactions for SCA
Not all transactions are needed to go through SCA by PSD2 directive due to the unavailability of cardholder to authenticate the transaction at the time of initiation and other limitations hence they are considered out of scope for SCA. We have listed them below.
Mail Order and Telephone Orders (MOTO) : MOTO transactions aren't considered to be online payments, so these are out of the scope.
Merchant-Initiated Transactions (MIT) : Payment(s) with fixed or variable amounts triggered by the merchant without direct involvement of the cardholder are out of scope. However, the initial Cardholder Initiated Transaction (CIT) should have gone through SCA and the cardholder should have agreed to the terms and conditions of the succeeding MITs.
Anonymous prepaid cards : Due to their very nature, payments made through an anonymous payment instruments such as anonymous prepaid (e.g.) gift cards, aren't subject to the obligation of strong customer authentication
Interregional transactions or One-leg transactions : Payments involving the card issued outside of PSD2 country/region are out of scope for strong customer authentication.
Authorization with SCA data
To perform an authorization with SCA data, you must include following properties in your create payment request.
Properties |
Explanation |
|---|---|
cardPaymentData.cardholderVerificationMethod |
Set the value to "THREE_DS" |
cardPaymentData.ecommerceData.threeDSecure.threeDSecureType |
Indicates the 3D-Secure type used in the transaction. Possible values and the conditions when to use are given below.
|
cardPaymentData.ecommerceData.threeDSecure.authenticationValue |
Holds the AAV of Mastercard or CAVV of Visa, DinersClub, UnionPay or JCB. |
cardPaymentData.ecommerceData.threeDSecure.directoryServerTransactionId |
The unique transaction identifier assigned by the Directory Server (DS) to identify a single transaction. |
cardPaymentData.ecommerceData.threeDSecure.version |
3D Secure version. Possible values are
|
cardPaymentData.ecommerceData.threeDSecure.eci |
Electronic Commerce Indicator indicating the level of authentication. Contains different values depending on the card scheme. |
Below code snippet shows the 3D-Secure authentication related properties that needs to be included in the authorization request.
{
"cardPaymentData": {
"cardholderVerificationMethod": "THREE_DS",
"ecommerceData": {
"threeDSecure": {
"threeDSecureType": "THREE_DS",
"authenticationValue": "AAABBEg0VhI0VniQEjRWAAAAAAA=",
"directoryServerTransactionId": "0759e8d6-cc20-4435-8ac8-ea9f225cb95f",
"version": "2.2.0",
"eci": "05"
}
}
}
}