By: Adeyinka Adegbenro
3-D Secure (3DS) is an authentication protocol that adds an extra layer of security for card payments. It helps verify that the legitimate owner of a card is the one making the purchase. It also often serves as a mechanism to fulfill Strong Customer Authentication (SCA), particularly in regions subject to regulations like the revised Payment Services Directive (PSD2), which mandates at least two forms of customer authentication.
While 3DS facilitates two-factor authentication for online payments, it’s designed to assess risk. This means not every payment requires an explicit challenge. Low-risk transactions can be completed through a frictionless flow without extra customer input. The protocol is meant to gauge if further security is needed for a specific transaction, and if so, the customer may be asked to input a PIN or a one-time password (OTP) sent to their device.
The challenge when integrating 3DS into a payment flow is creating a balance between security, user experience, and high authorization rates. While 3DS can enhance security, it can also introduce friction that leads to user abandonment and lower approval rates if not implemented carefully.
In this article, you’ll go through the process of implementing 3DS and learn how to strike the balance between security, user experience, and authentication rates.
Understanding the 3DS Flow: Frictionless vs. Challenge
The original 3DS protocol, 3-D Secure 1 (3DS1), was designed to protect merchants from fraudulent chargebacks by verifying cardholder identity, but it frequently led to significant user friction. Mobile browser incompatibility, slow authentication page loads, and a perceived lack of necessity often led to transaction abandonment.
Recognizing these challenges, 3-D Secure 2 (3DS2) leveraged a broader range of data to enable more accurate risk assessment and a smoother mobile experience. It introduced two main authentication paths: the frictionless flow and the challenge flow. In the frictionless flow, transactions can be approved without requiring any additional input from the cardholder. This occurs when a transaction is deemed low-risk through real-time risk-based analysis (RBA). On the flip side, if the RBA identifies a transaction as potentially high-risk, a challenge flow is initiated, prompting the user for further verification, such as an OTP, biometric authentication, or a PIN.
Choosing between a frictionless or challenge flow depends on numerous data points at the time of the transaction by both merchants and issuers. These data points can include device information, transaction amount, customer status (new or existing), transactional history, and geolocation. For instance, if a new card is used by a customer with no prior transaction history or an existing card is used on an unfamiliar device, the risk can be elevated, leading to a 3DS challenge. However, a customer with a card on file and a history of successful, non-fraudulent transactions can trigger a low-risk assessment, allowing the transaction to proceed via the frictionless flow, bypassing explicit 3DS authentication.
Developers should strive to minimize challenge flows and maximize frictionless outcomes by transmitting rich contextual data alongside payment information. The richer the data, the more accurately issuers can assess the customer’s true risk profile. This not only aids in satisfying issuer rules and regulatory requirements but also reduces checkout friction and improves conversion rates.
Balancing Security and User Experience
Minimizing challenge flows and maximizing frictionless outcomes keeps customers happy while still preventing fraud. In this section, you will learn strategies you can use to strike that balance when implementing 3DS.
Using 3DS Exemptions to Reduce Friction
3DS exemptions are specific provisions under regulations like PSD2 that allow certain transactions to bypass active cardholder authentication. These exemptions are primarily designed to reduce friction and enhance the user experience for lower-risk transactions.
Here are some common exemption types:
Low-Value Transactions
Developers can request a low-value exemption (LVE) for payments less than or equal to €30 (or its equivalent after currency conversion). This exemption applies as long as the cumulative sum of previous transactions by the same cardholder, since their last SCA, does not exceed a certain threshold (eg €100) or the number of consecutive low-value transactions does not exceed five, depending on the issuer’s enforcement policy.
To programmatically request this exemption, depending on your Payment Service Provider’s (PSP) API, you can set an exemption indicator. For example, with some APIs, you set payment_method_options.sca_exemption to LowValue.
Transaction Risk Analysis
Through transaction risk analysis (TRA), merchants or their payment providers can request a 3DS exemption for transactions they’ve internally assessed as low-risk. This exemption is useful for promoting customer retention by ensuring known or trusted customers are not subjected to unnecessary authentication. Merchants must analyze a transaction’s risk profile and confirm it as low-risk through their internal systems before requesting a TRA exemption.
For instance, a $20 USD order from a long-time customer using the same known device, IP address, and billing address, with no history of chargebacks, would be a strong candidate. The merchant would then flag this as low-risk and request the exemption via TRA. Programmatically, this can involve setting payment_method_options.sca_exemption to TransactionRiskAnalysis.
Credentials on File
Credentials on File (CoF) exemptions apply when charging a stored card from a returning customer. This typically involves the merchant or PSP securely storing a customer’s card details for future payments, such as recurring subscriptions, top-ups, or one-click reorders. There are two primary types of CoF transactions:
- Merchant-initiated transactions (MIT): This is for payments like a Netflix subscription, where the user is not actively present at the time of payment. The transaction is inherently exempt from SCA.
- Customer-initiated transactions (CIT): When a customer with their card on file chooses to reorder with a single click, they may qualify for a frictionless flow, provided the transaction meets other low-risk criteria.
While other exemptions, such as trusted beneficiaries, exist, they often require direct customer action (eg whitelisting a merchant on their issuer’s platform) and are less directly controlled by the merchant. This article focuses on merchant-initiated strategies.
Properly utilizing the exemptions mentioned here helps maximize frictionless flows and leads to a more seamless customer experience and faster payment approvals. However, note that requesting an exemption does not guarantee a frictionless flow. The issuer ultimately retains the right to override the exemption and mandate a challenge if they deem the transaction high risk.
Fine-Tuning the Challenge Indicator
Challenge indicators are optional parameters that merchants send to issuing banks to influence whether a transaction should undergo additional authentication (a challenge flow). This parameter is typically included within the payment request to your PSP. While specific implementations may vary between PSPs, a common representation can look like this:
"3DRequestorChallengeInd": "02"
Following are some common challenge indicators:
| Challenge Indicator Value | Meaning | Use Case |
|---|---|---|
| 01 | No preference | You let the issuer decide |
| 02 | No challenge requested | You want a frictionless flow |
| 03 | Challenge requested (merchant preference) | You prefer a challenge flow (eg suspicious activity, first-time user, new device) |
| 04 | Challenge requested (mandate) | You need a challenge flow as required by law (regulations the merchant is bound by or internal business rule) |
It’s important to note that issuers make the final decision. Even if you request a frictionless flow (02), the issuer may still challenge the transaction based on their risk analysis.
While requesting a challenge (03 or 04) can reduce fraud and liability, doing so unnecessarily may negatively impact your conversion rates. In contrast, strategically using 02 for low-risk transactions can improve authorization rates, but applying it too broadly to transactions that should have been challenged may lead to more chargebacks or soft declines.
A good starting point is to default to 01 (no preference) or 02 (no challenge requested) and adjust your strategy based on observation, user behavior, and fraud risk.
Passing More PII Means Fewer Challenges
Personally identifiable information (PII) comprises any data that can identify a specific individual. In the context of 3DS transactions, passing more PII can significantly increase the likelihood of a frictionless flow and improve the authentication experience for users.
Issuing banks heavily rely on the RBA to determine whether a 3DS transaction should proceed via a frictionless flow or require a challenge. The more context an issuer receives, the more accurately its risk engine (often powered by artificial intelligence (AI) / machine learning (ML) models) can assess the legitimacy of a transaction.
Merchants can significantly increase the likelihood of a frictionless flow by including a rich set of PII and other contextual data in their 3DS requests. When the issuing bank receives this detailed information, its RBA model can confidently look for signals of legitimacy and fraud, such as the following: Is this a known device? Is there a history of fraudulent activity associated with this IP address, email, or card? Is the transaction amount unusually high?
The more detailed PII the merchant provides, the better the RBA model performs, leading to more confident risk scoring and, ultimately, higher rates of frictionless authentication.
Here are some examples of valuable PII and metadata to include:
- Email address
- Phone number
- Billing address
- Device fingerprint
- Browser metadata
Developers should make every effort to provide as much optional customer metadata as possible in their 3DS requests to ensure the best outcomes and maximize frictionless flows.
Handling 3DS Failures and Soft Declines
It’s important to understand that a 3DS failure is not always the same as a final payment authorization decline. 3DS failures in online payments typically occur when a cardholder fails to correctly authenticate their transaction due to incorrect information input or because of technical issues within the authentication process itself. These outcomes can generally be categorized into two main types: hard declines and soft declines.
Hard Declines
Hard declines are final rejections of a payment where retrying the transaction is unlikely to succeed. Common scenarios include the following: the card not being enrolled in 3DS, the authentication explicitly rejected by the cardholder, or the issuer refusing to honor the transaction due to a card issue (eg lost, stolen, or account closed).
For hard declines, it’s best not to retry to avoid potential chargebacks or issuer penalties. For example, if a payment declines with a code like 63 - Cardholder not Enrolled, you should return a clear message to the customer, such as “Your card is not enrolled in secure authentication. Please use a different payment method.”
Soft Declines
Soft declines are usually not final and present an opportunity for retry. For instance, a merchant may initially attempt a frictionless flow for a payment, but the issuer can soft decline the transaction, requesting SCA on retry.
When faced with soft declines, issuers may require merchants to retry soft declined transactions with 3DS within a specific timeframe, often indicated by a Merchant Advice Code (MAC). MACs are signals sent by card networks like Mastercard in response to a declined transaction. They help merchants understand whether to retry a transaction or not.
Developers should build logic to handle these soft declines gracefully by retrying the same transaction but adjusting parameters to force a challenge on the second attempt (eg by setting the 3DS challenge indicator appropriately, which is platform dependent).
MACs are typically returned in the response of a failed 3DS transaction. These codes provide crucial guidance on the next steps to take. Here are a few examples of common MAC and their meanings:
| MAC | Meaning | What to Do |
|---|---|---|
| 62 | Restricted card | Do not retry the transaction |
| 65 | Exceeds withdrawal count limit | Retry with a 3DS challenge |
| 70 | Contact card issuer | Retry is not advised; may indicate final failure |
| 91 | Authentication not available; 3DS service down | Retry later or through different processor |
Keep in mind that the codes can vary slightly depending on the payment processor. Always consult your provider’s specific documentation. Decoding the MAC after a 3DS request has failed is essential for guiding developers to handle declines gracefully and optimize their payment flows.
Leveraging AI to Optimize 3DS Strategy
AI and ML offer a powerful avenue for optimizing your 3DS strategy. By combining data analysis and continuous learning, AI can help merchants and payment providers make smarter, adaptive decisions across the entire authentication funnel.
AI/ML can provide value in the following ways:
- Exemption prediction: AI can analyze historical transaction data, issuer behavior, transaction context, and user history to predict when an exemption (like TRA or LVE) is most likely to succeed or even when to avoid requesting an exemption entirely to avoid soft declines. For example, if an AI model learns that a specific issuer frequently declines TRA exemptions after 10 PM, it can dynamically adjust future attempts during that timeframe.
- Dynamic challenge indicator selection: Instead of relying on static, hard-coded values for the 3DS challenge indicator, an AI algorithm can analyze real-time data points, such as device information, customer behavior, and transaction amount, to assess the risk level of each payment. This assessment informs the selection of the most appropriate challenge indicator (eg
no_challenge_requestedfor low-risk,challenge_requestedfor high-risk). This approach helps developers better align with issuer policies, reduce friction for low-risk transactions, and avoid unnecessary declines due to mismatched challenge expectations. - PII level tuning: AI/ML can learn which specific PII and contextual data are most valued by different issuers. Some issuers can heavily weigh device data, while others prioritize email, IP location, or account tenure. An AI model can dynamically adjust the depth and type of information sent with each transaction to improve trust scores and increase the likelihood of frictionless flow.
These AI-driven optimizations thrive on real transaction feedback loops. Models continuously learn from outcomes, such as successes, declines, and fraud flags, to identify evolving risk patterns and refine their logic over time. This approach ensures that authentication strategies are constantly improving based on real-time transactions and customer context, rather than static rules.
The benefits of integrating AI into your 3DS strategy include higher conversion rates, effective fraud management, improved issuer alignment, and more frictionless flows.
Sample Project: 3DS Optimization Playground
To help developers visualize the concepts of 3DS optimization, this section explores a simple web-based simulator called the 3DS Optimization Playground. This application demonstrates how various parameters, such as transaction amount, CoF status, challenge indicators, and the presence of PII, can influence the outcome of a 3DS flow. All the source code is available on GitHub.
The simulator.html file is designed to run directly in a web browser without requiring a server-side component. Here’s a brief explanation of its key components:
- DOM element selection: The logic starts by selecting all the necessary HTML elements using
document.getElementByIdand storing them in constants for easy access:
const amountInput = document.getElementById('amount');
const cofStatusSelect = document.getElementById('cofStatus');
const challengeIndicatorSelect = document.getElementById('challengeIndicator');
const piiPresenceCheckbox = document.getElementById('piiPresence');
const aiModelToggle = document.getElementById('aiModelToggle');
const simulateBtn = document.getElementById('simulateBtn');
const outputSection = document.getElementById('outputSection');
const outcomeSpan = document.getElementById('outcome');
const frictionlessRateSpan = document.getElementById('frictionlessRate');
const challengeRateSpan = document.getElementById('challengeRate');
const failureRateSpan = document.getElementById('failureRate');
const exemptionReasonDiv = document.getElementById('exemptionReason');
const failureReasonDiv = document.getElementById('failureReason');
-
Global rates for AI model persistence: The
currentFrictionlessRate,currentChallengeRate, andcurrentFailureRatevariables are the base rates that define the probabilities of friction, challenge, and failure occurring in 3DS. They also get tuned in real time after every transaction so that the AI model simulator simulates a cumulative effect on the rates over time. -
Event listener: The
simulateBtn.addEventListener('click', simulate3DS)line attaches an event listener to the “Simulate 3DS Flow” button in the UI. When the button is clicked, thesimulate3DSfunction is called. -
simulate3DSfunction: This is the main function that performs the simulation.- Input retrieval: The function initially reads the current value of all input fields (
amount,cofStatus,challengeIndicator,piiPresence,aiModelToggle). - Initialization: This sets up variables to store the outcome and any specific reasons for the current run in variable
outcome,exemptionReason, andfailureReason. - Exemption evaluation: The next part of the function (lines 314–343) determines if the transaction is eligible for various 3DS exemptions (TRA, LVE, recurring payments). It sets
exemptionAppliedandexemptionReasonaccording to the exemption triggered. - ACS random challenge logic: Access Control Server (ACS) in payments is a system operated by the issuer to verify the cardholder’s identity. In the function, the ACS code block (lines 346–352) implements a one-in-four chance for the ACS to mandate a challenge if no exemption applies and the challenge indicator is “no preference” or “no challenge”.
- Outcome determination: Based on the combination of the challenge indicator, exemption eligibility, and the ACS-mandated challenge, the code block determines the final
outcomeof the 3DS flow (e.g., “Frictionless (Exempted)”, “Challenge (Mandated)”, “Frictionless”, “Failure”). - AI model impact (simplified): If the “Enable AI model” toggle is enabled, this section simulates how an AI may auto-tune parameters. It heuristically adjusts the global frictionless, challenge, and failure rates to favor more frictionless outcomes, demonstrating the concept of optimization.
- Rate normalization: Ensure the sum of frictionless, challenge, and failure rates always adds up to 100 percent to maintain probability consistency.
- Display results: Updates the application’s output section with the calculated outcome and rates. It also displays the
exemptionReasonorfailureReasonif applicable.
- Input retrieval: The function initially reads the current value of all input fields (
Test Cases for the 3DS Simulator
The following scenarios are designed to help you visualize the logic in the simulation. Open simulator.html with your preferred (modern) browser to play around with it. For each test case, enter the specified input values and click the Simulate 3DS Flow button to see the expected outcome.
Low-Value Exemption
This test case demonstrates a transaction that is automatically exempted from a challenge because the transaction value is low.
Inputs
- Transaction amount:
$25.00 - CoF status:
Not CoF - Challenge indicator:
No Preference - PII present?: Unchecked
- Enable AI model: Unchecked
Expected Outcome
- Outcome:
Frictionless (Exempted) - Exemption/optimization info:
Low Value Exemption (LVE): Transaction amount is below the low value threshold.
The simulator’s logic checks for the LVE initially. Since the amount is less than or equal to $30 USD, the transaction is immediately classified as frictionless without any further checks:
CoF Exemption
This scenario shows how a recurring payment from a trusted customer can be exempted from a challenge, even with a higher transaction amount.
Inputs
- Transaction amount:
$75.00 - CoF status:
Merchant Initiated Transaction (MIT) - Challenge indicator:
No Preference - PII present?: Unchecked
- Enable AI model: Unchecked
Expected Outcome
- Outcome:
Frictionless (Exempted) - Exemption/optimization info:
Recurring Payments/MIT Exemption: Transaction is a CoF payment.
The simulator prioritizes CoF transactions as a valid exemption reason. Even though the amount is above the LVE threshold, the cofStatus of merchant-initiated signals a recurring payment, which is considered low-risk and therefore frictionless:
Challenge Mandated
This demonstrates a scenario where a challenge is unavoidable, regardless of other factors, because it has been explicitly requested.
Inputs
- Transaction amount:
$15.00 - CoF status:
Not CoF - Challenge indicator:
Challenge Mandated - PII present?: Checked
- Enable AI model: Unchecked
Expected Outcome
- Outcome:
Challenge (Mandated) - Exemption/optimization info: No message
The Challenge (Mandated) indicator acts as an override. It bypasses all exemption logic and forces a challenge, which is useful for transactions deemed high-risk by the merchant or when required by regulations:
AI Model Tuning
This test highlights the dynamic nature of the AI model. You have to run this simulation with the AI toggle checked multiple times to see the effect.
Inputs
- Transaction amount:
$100.00 - CoF status:
Not CoF - Challenge indicator:
No Preference - PII present?: Checked
- Enable AI model: Checked
Expected Outcome
- Outcome: Over multiple runs, the
Frictionless Rategradually increases, and theChallenge RateandFailure Ratedecrease with each successful frictionless or challenged outcome. - Exemption/optimization info: If a frictionless outcome occurs without an exemption, the message is
AI Model Optimization: Transaction identified as low risk for frictionless flow.
With the AI model enabled, it learns from each transaction outcome by adjusting the underlying success rates:
Conclusion
When implementing 3DS, it’s easy to become focused on the enhanced security that additional authentication layers provide, inadvertently overlooking the friction that comes with it. A balance must be struck: merchants who lean too heavily toward either extreme risk, rampant insecurity, and fraud in their payment funnel, or those who suffer from high abandonment rates due to excess customer friction.
In this article, you learned how to achieve the optimal balance between security and a great user experience. You saw strategies, like 3DS exemptions, challenge indicator parameters, data enrichment in payment requests using PII, and 3DS failure management, and you learned how to harness the power of AI and ML models for 3DS optimization.