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
- 6
- Available on
- All plans
Global enterprise merchants face complex authentication requirements when processing cross-border payments. Issuing banks rely on detailed transaction information to assess fraud risk, and poorly structured data requests frequently trigger unnecessary buyer challenges. The payment infrastructure must format these messages correctly to prevent legitimate customers from abandoning their shopping carts during checkout.
Cardflo configures the authentication infrastructure by formatting 3DS2 message structures to align with regional issuer preferences. The platform identifies the correct protocol versions and populates data fields accurately for both customer and merchant initiated transactions. This data enrichment allows acquirer partners to submit high-quality requests that maximise global authorisation 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
Global checkout performance depends heavily on the quality of data exchanged between the merchant and the cardholder's issuing bank. Cardflo manages this critical authentication layer by refining message structures and formatting device data to meet varied regional standards.
The orchestration platform evaluates transaction parameters to populate the correct fields for both initial purchases and subsequent merchant initiated transactions, ensuring that issuers receive the exact intelligence needed to confidently approve the payment. This structural fine-tuning sits distinctly apart from handling soft declines, which requires automated step-up sequences managed through 3DS-fallback.
By correctly formatting the protocol payload and identifying optimal global versions, the integration prevents unnecessary buyer challenges and reduces cart abandonment across multiple international markets without adding friction to the core purchasing experience.
How 3DS optimisation works
Protocol version identification
The orchestration layer queries the card network directory to determine the exact protocol versions supported by the cardholder's issuing bank. The system selects the highest mutually supported standard before initiating the authentication request. This initial verification ensures that the merchant submits the transaction using the exact technical framework the issuer expects to process, avoiding unnecessary errors.
Message payload formatting
The platform extracts device data, billing details and transaction history from the checkout session to construct the authentication message. The system maps these data points to the required fields within the active protocol version. Proper formatting guarantees that the issuing bank receives a comprehensive profile of the buyer, which reduces the likelihood of an active challenge.
Merchant initiated transaction flags
Finance teams process recurring payments and subscription renewals by flagging the authentication request as a merchant initiated transaction. The platform populates the message structure with the original network reference identifier from the initial customer session. This structured approach informs the issuer that the cardholder is not present, ensuring the request proceeds correctly without requiring active buyer input.
Why 3DS optimisation matters
Lower global cart abandonment
Poorly formatted authentication requests force issuing banks to challenge buyers with additional security steps, leading directly to dropped sessions. Structuring the data payload correctly gives the issuer the confidence to approve the transaction immediately. Merchants capture more revenue by preventing technical interruptions during the most sensitive final stage of the checkout process.
Improved authorisation confidence
Issuing banks rely heavily on structured data to verify legitimacy. When merchants supply complete device intelligence and precise billing matches within the protocol payload, the issuer's risk systems score the request more favourably. This rich data exchange leads to higher overall approval ratios across the acquirer partner network without increasing the merchant's exposure to fraudulent activity.
Regulatory notes for 3DS optimisation
Scheme directory server compliance
Card networks require merchants to query the directory server to establish the correct protocol capabilities before transmitting an authentication request. Failure to verify the issuer's readiness can result in compliance violations and increased network fees for submitting incorrectly formatted messages.
Proper version checking remains mandatory for global operations.
The orchestration platform manages this directory interaction automatically, logging the required proof of contact for each transaction. This verifiable audit trail demonstrates that the merchant attempted authentication using the mandated technical standards, protecting the business from scheme penalties and maintaining good standing with acquirer partners.
Network reference identifier mandates
Card schemes mandate that merchants link all subsequent recurring payments to the initial customer authentication using a network transaction identifier. This cryptographic link proves to the issuing bank that the cardholder originally authorised the mandate, making it a critical requirement for subscription billing compliance.
If the merchant fails to populate this specific field within the message structure, the issuer must treat the request as an unauthenticated, cardholder-present transaction.
This error inevitably triggers a challenge that the absent buyer cannot complete, leading to declined renewals and potential scheme scrutiny for incorrect transaction flagging.
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
- Format protocol message structures to ensure issuing banks receive complete device and transaction data points.
- Identify the optimal protocol version supported by specific regional issuers to prevent unnecessary authentication failures.
- Populate critical data fields accurately to distinguish customer purchases from scheduled merchant initiated transactions.
- Validate browser and device information before transmission to meet the exact technical requirements of the protocol.
- Transmit detailed billing and shipping address matches within the payload to build confidence with the issuing bank.
- Align data formats with the specific scheme rules required by acquirer partners across different global regions.
A short scoping call, then a written plan for your MIDs.
Questions about 3DS optimisation
How does protocol versioning impact global authentication success?
Different regional issuers support different iterations of the protocol, and submitting a request using an incompatible version results in an immediate failure. The orchestration layer checks the directory server to identify the specific version the issuer prefers, such as version 2.1 or 2.2.
The platform then structures the payload to match the data fields available in that specific iteration. By adapting to the issuer's technical capabilities, merchants prevent format-related rejections and maintain high approval rates across their acquirer partner network.
What data points are required to avoid unnecessary buyer challenges?
Issuing banks evaluate dozens of data fields within the message structure to determine whether a transaction requires further verification. The orchestration system populates critical elements such as browser IP addresses, device language settings, email addresses and billing matches.
Transmitting this rich context allows the issuer's risk models to verify the cardholder's identity passively. When the payload contains sufficient high-quality data, the bank is far less likely to demand a visible challenge, preserving the checkout experience.
How are merchant initiated transactions formatted within the protocol?
Recurring payments and delayed charges require a specific flag within the message structure to indicate that the customer is not actively participating in the session. The platform configures the request to include the network transaction identifier from the original authenticated purchase.
This reference links the new charge to the established mandate, proving to the issuer that the buyer previously consented to the agreement. Proper formatting ensures these background transactions clear successfully without triggering active authentication prompts.
Can the message structure adapt to specific issuing bank preferences?
Yes, different issuing banks place varying levels of importance on specific data fields within the payload. The orchestration platform formats the request to ensure the most critical information required by a specific region or bank is present and accurately mapped.
While the core protocol remains standard, this deliberate data population strategy caters to the nuanced risk models deployed by different institutions, allowing the acquirer partners to secure higher authorisation rates for the merchant.
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.