3DS optimisation
Cross-border checkouts depend on accurate authentication data and appropriate protocol versions. 3D Secure optimisation reduces unnecessary buyer challenges through correctly formatted 3DS2 messages for customer and merchant initiated transactions.
- Category
- Security
- Capabilities
- 10
- Available on
- All plans
Cardflo's 3DS optimisation enhances transaction security and approval rates without compromising customer experience. We intelligently apply 3D Secure protocols, balancing authentication requirements with conversion goals.
Our system adapts to issuer requirements and merchant risk profiles for optimal performance.
PCI scope is minimised through hosted fields and network tokens, and sensitive credentials never touch your servers. Strong Customer Authentication is applied intelligently to keep both regulators and conversion teams happy.
3DS optimisation overview
3DS optimisation refers to the strategic management of 3D Secure protocols to balance payment security with transaction throughput. While Strong Customer Authentication (SCA) is a regulatory requirement under PSD2 for European Economic Area transactions, its application elsewhere remains variable.
Merchants must navigate different versions of the protocol, primarily 3DS2, to utilise data-rich exchanges that facilitate frictionless authentication. This process sits between the gateway and the card schemes, acting as a verification layer before the authorisation request reaches the issuer.
Effective optimisation involves analysing issuer behaviour and risk signals to determine when a challenge is necessary. If mismanaged, 3DS can introduce latency or unnecessary friction, leading to basket abandonment.
By refining when and how these protocols are triggered, businesses may improve their authorisation rates while maintaining a robust defence against fraudulent activity and shifting the liability for chargebacks to the card issuer.
How 3DS optimisation works
Data gathering and risk analysis
The system collects transaction metadata including the BIN, MCC, and device fingerprints. These variables are analysed against historical issuer performance to determine the likelihood of a frictionless flow. This initial stage ensures that the subsequent 3DS request contains sufficient data to satisfy the issuer's risk engine without requiring manual input.
Protocol version selection
The gateway identifies whether the issuer supports 3DS 2.1, 2.2, or legacy versions. It prioritises the latest available version to enable biometric authentication and app-to-app redirection. This reduces the reliance on traditional SMS one-time passwords, which are known to have higher failure rates in mobile commerce environments.
Exemption management and application
Transaction Risk Analysis (TRA) or Low Value Payment (LVP) exemptions are applied where applicable under PSD2 frameworks. The system evaluates if the transaction meets the criteria to bypass a challenge entirely. This technical request is sent to the acquirer, who then communicates the exemption preference to the issuer.
Dynamic challenge handling
If the issuer requests a challenge, the platform manages the user interface transition to ensure the authentication frame loads correctly. It monitors for timeouts or refusal codes during this phase. If a technical failure occurs, the system can attempt a fallback or log the specific refusal reason for analysis.
Why 3DS optimisation matters
Reduction in checkout friction
Excessive authentication requests often lead to customer drop-off at the final stage of the purchase. By intelligently applying exemptions and favouring frictionless flows, merchants can minimise the number of steps a customer must take. This is particularly relevant for repeat transactions where a Merchant Initiated Transaction (MIT) or a trusted beneficiary status may be applicable under current regulations.
Authorisation rate improvement
Issuers are increasingly likely to decline transactions that do not have associated 3DS data, citing security concerns or regulatory non-compliance. Optimisation ensures that the issuer receives the specific data points they require to approve the transaction. By aligning with issuer preferences, merchants can reduce the frequency of soft declines and improve the overall success rate of their payment processing.
3DS optimisation use cases
Merchant initiated payment chains
Merchants initiating later payments without cardholder presence must preserve the original 3DS2 authentication context and network transaction identifiers, or issuers may misclassify the instruction. Cardflo helps payment teams map initial cardholder initiated transactions to subsequent merchant initiated transactions and populate the required protocol fields consistently.
Regional protocol version management
Enterprise merchants encounter issuers and access control servers supporting different 3DS protocol versions, message categories and optional data elements across markets. Cardflo helps teams maintain version-aware authentication requests, validate regional payload requirements and monitor approval and challenge outcomes by issuer country, card scheme and device channel.
Issuer challenge reduction
Merchants with elevated challenge rates often omit device, account history, delivery and cardholder data that issuers use when assessing a 3DS2 authentication request. Cardflo helps payment teams enrich and validate authentication payloads, then analyse challenge rates and checkout abandonment by issuer, scheme, market and transaction type.
Browser and app authentication
Merchants operating web and native app checkouts must construct different 3DS2 browser and SDK messages, with accurate device information, display parameters and completion indicators. Cardflo supports channel-specific payload design and reporting, helping teams identify authentication failures, excessive challenges and abandonment across browser, iOS and Android payment journeys.
3DS optimisation by the numbers
This is a typical range observed for merchants using advanced data sharing and exemption strategies within regulated markets, although individual results vary by sector.
Industry benchmarks suggest this range of improvement in approval rates when moving from legacy 3DS1 to optimised 3DS2 protocols due to better issuer data.
Modern 3DS server responses are typically expected within this timeframe to ensure the user experience remains stable during the transition between the merchant site and the issuer.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with 3DS optimisation
- Identify and apply the most recent 3DS2 protocol versions supported by the issuing bank.
- Utilise Transaction Risk Analysis to request exemptions for low-risk, high-volume payment flows.
- Monitor issuer-specific refusal reasons to refine future authentication and challenge strategies.
- Facilitate frictionless flows by transmitting enriched device and browser metadata to issuers.
- Automate the transition between 3DS versions to ensure compatibility with legacy banking systems.
- Capture and analyse abandonment data at the authentication stage to identify technical friction.
- Manage the liability shift for fraud-related disputes according to card scheme rules.
- Support app-to-app redirection for modern mobile banking authentication workflows.
- Configure custom rules for challenge triggers based on MCC or transaction value.
- Integrate with multiple 3DS Server providers to ensure high availability and redundancy.
A short scoping call, then a written plan for your MIDs.
Questions about 3DS optimisation
What is the difference between a frictionless flow and a challenge flow in 3DS2?
A frictionless flow occurs when the issuer receives sufficient data from the merchant to verify the cardholder's identity without requiring their active participation. The transaction is authorised silently in the background.
In contrast, a challenge flow requires the customer to perform an action, such as entering a code from an SMS or approving the transaction within their banking app.
Optimisation aims to maximise the percentage of frictionless flows while remaining compliant with security requirements, as this reduces the likelihood of the customer abandoning the checkout process.
How does 3DS optimisation impact the liability for chargebacks?
When a transaction is successfully authenticated through 3DS, the liability for fraudulent disputes typically shifts from the merchant to the card issuer. This applies even if a frictionless flow is used, provided the protocol was correctly implemented.
However, this shift does not usually apply to other chargeback types, such as 'goods not received' or 'not as described'. It is a targeted defence mechanism against unauthorised usage.
Consistent use of 3DS can therefore significantly reduce a merchant's exposure to fraud-related financial losses.
Can a merchant bypass 3DS for all transactions to improve conversion?
In certain jurisdictions like the EEA and UK, bypassing 3DS for all transactions is not possible due to PSD2 and SCA regulations. Issuers will likely decline non-compliant transactions with a soft decline code, requiring the merchant to resubmit with authentication.
In non-regulated markets, merchants can choose to bypass 3DS, but they must weigh the potential conversion benefit against the increased risk of fraud and the loss of the liability shift. Most businesses favour a hybrid approach based on risk assessment.
What happens if an issuer does not support the latest version of 3DS?
The optimisation logic should include a fallback mechanism. If an issuer does not support 3DS2, the system should ideally attempt to use 3DS1 or proceed without authentication if the risk profile allows and regulations permit.
However, 3DS1 is being phased out by major card schemes like Visa and Mastercard. If no version is supported, the transaction may be processed as a non-3DS payment, though this carries higher risk and may be rejected by the issuer's security systems.
How do SCA exemptions work within the context of 3DS optimisation?
Under PSD2, certain transactions may be exempt from Strong Customer Authentication. Common exemptions include low-value payments (under €30), recurring transactions after the initial setup, and payments to trusted beneficiaries.
A merchant can request these exemptions via their PSP or gateway. The issuer, however, has the final decision on whether to accept the exemption or demand a challenge.
Optimisation involves correctly flagging these requests to increase the probability that the issuer will allow the transaction to proceed without a challenge.
Does 3DS2 work equally well on all mobile devices and browsers?
While 3DS2 is designed to be mobile-compatible, performance can vary based on the implementation and the cardholder's banking app. Technical issues like iframe blocking, cookie restrictions in modern browsers, or poor app-to-app redirection can cause failures.
3DS optimisation includes monitoring these technical signals and adjusting the implementation to ensure the authentication interface renders correctly across the widest possible range of hardware and software configurations.
How is the success of a 3DS optimisation strategy measured?
Success is primarily measured by the authentication success rate, the frictionless flow rate, and the subsequent authorisation rate. Merchants should also monitor the '3DS abandonment rate', which tracks customers who reach the authentication stage but do not complete it.
A successful strategy will show a high percentage of frictionless approvals and a low rate of abandonment, indicating that security measures are not significantly hindering the customer journey.
Related features.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.