3-D Secure and SCA
Understand 3-D Secure and SCA
When making transactions online, protection from fraud is key – for both your customers and you.
To accommodate to this need, the payments industry has established the 3-D Secure authentication protocol (which stands for Three Domain Secure). For any card transaction, your customers must prove themselves to be the rightful card owner.
The current 3-D Secure standard requires your customers to pass the authentication via Strong Customer Authentication (SCA). Thus, your customers have to authenticate themselves 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)
Complying to SCA offers two big assets for your customer and you:
- Fraud protection: If a transaction turns out to be fraudulent, neither you nor your customer are liable. Instead, the issuer will compensate for the financial loss
- Flexibility and enhanced customer experience: In some cases, the authentication process may run in the background, making it imperceptible for your customers. Sometimes it is even possible to skip 3-D Secure altogether. Read our dedicated chapter to learn more
To further enhance the flexibility and enhanced customer experience, the European Union allows to either exclude or exempt certain transactions from SCA:
-
Exclusions – The following use cases are considered out-of-scope
Transactions through mail orders or telephone orders (MOTO)
Transactions for which your acquirer or your customer’s issuer is located outside of the EEA zone
Anonymous prepaid cards up to €150 (Article 63)Our platform detects these exclusions automatically, freeing you from indicating them in your transaction requests
- Exemptions – To enhance your customers’ payment experience, you can request skipping the authentication process if a transaction meets certain conditions. Read our dedicated chapter to learn more
Understand 3-D Secure transaction flow
For card payments, your customers have to authenticate themselves as the rightful card owners at one point. A typical payment flow goes like this:
- Your customers finalise an order in your shop and select a card payment method
- You send a CreateHostedCheckout/CreatePayment request to our platform, including a set of mandatory/recommended/optional 3-D Secure properties
- Our platform sends you a response with instructions for the next steps of the flow. Depending on the integration mode, differences apply:
a. Hosted Checkout Page: The response contains a redirectUrl to our secure payment page. Once you redirect your customer to this URL and they enter their card number, our platform will automatically cover any 3-D Secure-related steps for you
b. Hosted Tokenization Page/Server-to-server/Mobile/Client Integration: The response contains a merchantAction object, instructing you to redirect your customers to a specific URL. This URL is your customers' issuer - Your customers provide their credit card number and are redirected to their issuer for 3-D Secure authentication
- Our system receives the 3-D authentication result from the issuer
- We process the transaction and receive the result from the acquirer
- We redirect your customer to your returnUrl
- You request the transaction result from our platform via GetPayment or receive the result via webhooks
Implement 3-D Secure
With the exception of integration mode Hosted Checkout Page, you need to adapt your integration to ensure 3-D Secure is rolled out during the payment flow.
You achieve this by following two steps:
- Collecting data from your customers during the checkout process in your webshop environment
- Sending this data to our platform in the actual payment request. You need to send this data by adding
a. A fixed set of mandatory and
b. A selection of recommended and/or optional properties to your request
The more mandatory/optional parameters you add to your request, the higher the chance that the 3-D Secure authentication check becomes a mere background process. The payment process follows the so-called “frictionless flow”, improving the overall payment experience, as it becomes more seamless. Read our dedicated chapter to learn more.
For all other integration modes, check our dedicated guides for code samples/JSON covering the mandatory properties:
Hosted Tokenization Page
Server-to-server/Mobile/Client Integration
Refer to our test cases to simulate different authentication/transaction result scenarios for any card scheme
Mandatory properties
These are the basic properties you need to send for every card transaction in your CreatePayment request. If you are processing transactions via our Hosted Checkout Page solution, we will capture this data for you on our secure payment page.
cardPaymentMethodSpecificInput.card.cardholderName
cardPaymentMethodSpecificInput.threeDSecure.redirectionData.returnUrl
cardPaymentMethodSpecificInput.threeDSecure.skipAuthentication
order.customer.device.acceptHeader
order.customer.device.browserData.colorDepth
order.customer.device.browserData.javaEnabled
order.customer.device.browserData.screenHeight
order.customer.device.browserData.ScreenWidth
order.customer.device.locale
order.customer.device.timezoneOffsetUtcMinutes
order.customer.device.userAgent
If you process transactions for Carte Bancaire, make sure to add the following mandatory properties as well:
paymentProduct130SpecificInput.threeDSecure.useCase
order.customer.device.ipAddress
Recommended properties
The major card schemes highly recommend including these, as they will enhance the chance of a frictionless flow.
order.customer.billingaddress.city
order.customer.billingAddress.countryCode
order.customer.billingAddress.street
order.customer.billingAddress.houseNumber
order.customer.billingAddress.additionalInfo
order.customer.billingAddress.zip
order.customer.contactDetails.emailAddress
Optional properties
In addition, you can send from these as many as you wish. The more parameters you send, the higher the chance of a frictionless flow.
cardPaymentMethodSpecificInput.priorThreeDSecureData.acsTransactionId
cardPaymentMethodSpecificInput.priorThreeDSecureData.utcTimestamp
cardPaymentMethodSpecificInput.threeDSecure.challengeIndicator
cardPaymentMethodSpecificInput.threeDsecure.priorThreeDSecureData.method
cardPaymentMethodSpecificInput.threeDSecure.secureCorporatePaymentcardPaymentMethodSpecificInput.threeDSecure.challengeCanvasSize
Mpi.cardholderAccountChange
order.additionalInput.airlineData.flightIndicator
order.additionalInput.airlineData.passengers.airlineLoyaltyStatus
order.additionalInput.airlineData.passengers.passengerType
order.additionalInput.airlineData.ticketCurrency
order.additionInput.typeInformation.transactionType
order.customer.account.authentication.method
order.customer.account.authentication.utcTimestamp
order.customer.account.changeDate
order.customer.account.changedDuringCheckout
order.customer.account.createDate
order.customer.account.hadSuspiciousActivity
order.customer.account.passwordChangeDate
order.customer.account.passwordChangedDuringCheckout
order.customer.account.paymentAccountOnFile.createDate
order.customer.account.paymentAccountOnFile.numberOfCardOnFileCreationAttemptsLast24Hours
order.customer.account.paymentActivity.numberOfPaymentAttemptsLast24Hour
order.customer.account.paymentActivity.numberOfPaymentAttemptsLastYear
order.customer.account.paymentActivity.numberOfPurchasesLast6Months
order.customer.accountType
order.customer.contactDetails.mobilePhoneNumber
order.customer.contactDetails.phoneNumber
order.customer.contactDetails.workPhoneNumber
order.shipping.address.additionalInfo
order.shipping.address.city
order.shipping.address.countryCode
order.shipping.address.houseNumber
order.shipping.address.street
order.shipping.address.zip
order.shipping.addressIndicator
order.shipping.emailAddress
order.shipping.firstUsageDate
order.shipping.isFirstUsage
order.shipping.type
order.shoppingCart.giftCardPurchase.amountOfMoney.amount
order.shoppingCart.giftCardPurchase.amountOfMoney.currencyCode
order.shoppingCart.giftCardPurchase.numberOfGiftCards
order.shoppingCart.isPreorder
order.shoppingCart.preorderItemAvailabilityDate
order.shoppingCart.reorderIndicator
Implement external MPI for 3-D Secure check
Depending on your business model, you might prefer working with an external Merchant Plug-In (MPI) to process 3-D Secure-proof payments.
We have designed our platform in a way that allows you to split the transaction flow into two separate phases:
- Rollout 3-D Secure with your external MPI
- Process the actual transaction via our platform. Add the following nested properties in object cardPaymentMethodSpecificInput.threeDSecure properties to a standard CreatePayment request:
{
"cardPaymentMethodSpecificInput": {
"card": {
"cvv": "451",
"cardNumber": "4012005616165343",
"expiryDate": "1223",
"cardholderName": "Wile E. Coyote"
},
"isRecurring": false,
"paymentProductId": 1,
"transactionChannel": "ECOMMERCE",
"threeDSecure": {
"externalCardholderAuthenticationData": {
"cavv" : "AAABBEg0VhI0VniQEjRWAAAAAAA=",
"cavvAlgorithm" : "X",
"directoryServerTransactionId" : "f25084f0-5b16-4c0a-ae5d-b24808a95e4b",
"eci" : "05",
"threeDSecureVersion" : "2.1.0",
"acsTransactionId" : "abcdefghijklmnopqrstuvwxyz0123456789",
"flow" : "challenge"
}
}
},
"order": {
"amountOfMoney": {
"currencyCode": "EUR",
"amount": 2980
},
"customer": {
"billingAddress": {
"countryCode": "NL"
}
},
"references": {
"merchantReference": "oGPc8xJURfpFitBa6ORrpkBuPoGpvD"
}
}
}
Property | Remarks |
---|---|
cavv | Mandatory |
eci | |
threeDSecureVersion | |
directoryServerTransactionId | |
acsTransactionId | |
xid |
Optional Your external MPI's reference to the authentication result |
flow |
Optional If left out, our platform will populate this property with frictionless, which we will include in GetPaymentDetails responses. |
If you process transactions for Carte Bancaire, make sure to add the following mandatory properties as well:
cavvAlgorithm
schemeRiskScore
appliedExemption
Conceal or skip 3-D Secure authentication
The SCA guidelines come with a set of features that allow you to:
- Implement the authentication step as a background process (the so-called frictionless flow), making it imperceptible for your customers. If needs be, you can also request the full authentication process (the so-called challenge flow)
- Skip 3-D Secure altogether if certain conditions are met. We offer various features that allow this
Learn here how to implement these features in a safe and compliant way.
Implement Challenge/Frictionless flow
Whenever you send a card transaction request to our platform, two 3-D Secure authentication scenarios are possible:
-
Frictionless flow: You have provided enough information in the mandatory/recommended/optional properties about the cardholder in the transaction request itself. Hence, the cardholder’s issuer considers the risk of a fraudulent use of the credit card in question low. Consequentially, your card holder does not have to authenticate her/himself at the issuer’s site: There is no redirection to the issuer from our secure payment page (for Hosted Checkout Page transactions) or your check-out page (for Hosted Tokenization Page/Server-to-Server/Mobile integration mode). By skipping this step in the transaction flow, the overall payment experience becomes a lot smoother.
To enhance the chances of a frictionless flow, send as many recommended/optional properties in your request. Add optional parameter cardPaymentMethodSpecificInput.threeDSecure.challengeIndicator="no-challenge-requested" to your request
However, some issuers will still insist the card holder authenticate her/himself. This will result in a challenge flow
-
Challenge flow: Regardless of what you have provided in the mandatory/recommended/optional properties about the cardholder, the issuer insist the cardholder authenticate her/himself. Consequentially, there is a redirection to the issuer from our secure payment page (for Hosted Checkout Page transactions) or your check-out page (for Hosted Tokenization Page/Server-to-Server/Mobile integration mode).
In some cases (especially when creating a token for recurring payments), you might want to enforce yourself the challenge flow. Add optional parameter: cardPaymentMethodSpecificInput.threeDSecure.challengeIndicator=" challenge-requested" or "challenge-required" to your request
Implement SCA exemptions
Unlike SCA exclusions, you need to actively request SCA exemptions in your transaction requests. Transaction eligible for exemptions are:
- White-listed merchants: Your customers can request an exemption to their issuer to white-list you as a "trusted beneficiaries"
- Corporate transactions: Transactions between two corporations
- Acquirer TRA (Transaction Risk Analysis): You can request an exemption for transactions you consider low risk. As the acquirer is liable, it decides to grant/reject an exemptions based on the overall portfolio of the transaction (transaction value, fraud rate)
- Issuer TRA: The customer’s issuer can request an exemption if you or the acquirer did not. As the issuer is liable, it decides to grant/reject an exemptions based on the overall portfolio of the transaction (transaction value, fraud rate)
- Low amount transactions: For purchases lower than €30. However, SCA will be necessary if a customer makes five transactions in a row or reaches a value of more than €100
- Delegated authentication (certified wallet): An issuer can give authority to a third-party such as a certified wallet provider or a merchant to perform SCA on their behalf
Depending on the card scheme, it requests an exemption this in one of the two ways:
- On authentication level: Add cardPaymentMethodSpecificInput.threeDSecure.challengeIndicator and cardPaymentMethodSpecificInput.threeDSecure.exemptionRequest with the appropriate values (depending on the use case) to your request
- On authorisation level: Add cardPaymentMethodSpecificInput.threeDSecure.skipAuthentication and cardPaymentMethodSpecificInput.threeDSecure.exemptionRequest with the appropriate values (depending on the use case) to your request
Contact your card scheme which is the appropriate one and adapt your CreatePayment/CreateHostedCheckout request accordingly.
Check payment.paymentOutput.CardPaymentSpecificOutput.threeDSecureResults.appliedExemption from our response whether the issuer has granted the exemption. If the issuer declines the transaction(statusOutput=2), our platform returns errors.errorCode=40001139.
Mind that
- You are liable for fraudulent transactions if the issuer accepts the transaction without 3-D Secure. Check property paymentOutput.cardPaymentMethodSpecificOutput.threeDSecureResults.liability for GetPayment/GetPaymentDetails requests. Be aware that this is only an indication, as the definite accountability depends on various factors
We recommend sticking to the frictionless flow feature if you prefer to keep your liability protection - We offer the Exemption Engine feature that automatically requests exemptions when applicable. Read our dedicated chapter to learn more
Implement Soft Decline feature
SCA guidelines allow you process transactions via the frictionless flow. However, there is always a chance that your customer’s bank insist on the challenge flow, resulting in a declined transaction. Our Soft Decline mechanism allows you to recover these transactions. Read our dedicated guide to learn more.
Implement Exemption Engine
If a transaction meets specific requirements, it is exempt from 3-D Secure. However, checking these requirements and sending appropriate payment requests adds complexity to your integration efforts. Our Exemption Engine feature offers a welcoming relief. Read our dedicated guide to learn more.
Implement Decoupled amount feature
It is possible to process different amounts during the authentication (the 3-D Secure check) and the authorisation (blocking the funds on your customers’ credit card). This feature is very helpful for processing delayed/partially split payments or incrementing an authorised amount. Read our dedicated guide to learn more.
Understand 3-D Secure statuses
To help you keep track of your transactions and their 3-D Secure status, it is important to differentiate between a transactions':
- 3-D Secure status: The result of the authentication check provided by your customer’s issuer. We return this result in property paymentOutput.cardPaymentMethodSpecificOutput.threeDSecureResults.eci in GetPayment/GetPaymentDetails requests
- Global transaction status: The result of the authorisation request provided by your acquirer for the gross amount (as defined in your CreatePayment/CreateHostedCheckout request in property order.amountOfMoney.amount). We return this result in property statusOutput.statusCode. Learn more about the global transaction status and all possible outcomes
The table below gives you a full overview of possible scenarios and how our platform displays them to you:
3-D Secure status GetPayment/GetPaymentDetails in property eci |
Transaction status GetPayment/GetPaymentDetails in property statusCode |
Description |
---|---|---|
5 | Depending on the authorisation result by your acquirer either 2 5 9 |
Your customers have passed the authentication (via a challenge or frictionless flow). In case of fraudulent chargebacks, the issuer is liable |
6 |
Depending on the authorisation result by your acquirer either 2 5 9 |
Your customers did not have the opportunity to perform the authentication check. In case of fraudulent chargebacks, the issuer is liable |
91 | 2 | Your customers did not pass the authentication check because of i.e. incorrect password/PIN. Our platform does not execute the authorisation step at all, abandoning the transaction |
92 | 2 | Authentication was not possible due to a technical error. Our platform does not execute the authorisation step at all, abondoning the transaction (statusCode=2) |