Stop showing issuers only your riskiest customers

How 3DS Data Only helps recover sales and improve payment economics

A legitimate customer reaches checkout. Your fraud tools are comfortable with the purchase. The issuing bank declines it anyway. Somewhere between the customer relationship you understand and the payment decision the bank makes, useful context has been lost.

Data Only gives payment teams a way to address that gap. It uses 3-D Secure (3DS) infrastructure to share additional transaction information without asking the customer to complete an authentication challenge. For merchants, payment service providers and acquirers, the opportunity is to help improve authorization outcomes by providing additional transaction context while preserving a frictionless checkout experience.

For a Payment Service Provider (PSP) or acquirer, that opportunity can extend across a merchant portfolio. My view is that Data Only deserves a place in the payment performance conversation. The commercial question is how to use it effectively across your own traffic, with accurate data, the right transactions and a measurement plan that shows whether it pays.

What Data Only actually does

A Data Only flow shares transaction context for risk assessment without performing full cardholder authentication. It must be distinguished from frictionless 3DS authentication, where an issuer can authenticate a transaction without showing a challenge. Both can be invisible to the shopper, but their outcomes and liability implications differ. Data Only does not provide the authentication liability shift; the merchant retains fraud liability.

The flow also depends on the scheme. Implementations differ, including whether the data goes to the issuer’s Access Control Server or is assessed at the network level. In Mastercard’s Identity Check Insights flow, Mastercard generates Digital Transaction Insights (DTI) and sends them to the issuer during authorization. These additional risk signals complement the issuer’s own information, helping it make a more informed approval decision. Buyers should ask which implementation their provider supports rather than assume every Data Only offering works identically.

The final approval still belongs to the issuer. Better context can help that decision, but sending data does not guarantee an approval.

Why does sharing more help? Where 3DS isn’t mandated, merchants tend to authenticate only the transactions that already look risky. Issuers then see authentication mostly on risky traffic, so it starts to read as a risk signal rather than a trust signal, and approvals suffer. That’s a deployment problem, not a protocol failure, and it was a theme of our April 2026 discussion with Stripe on Glenbrook’s Payments on Fire podcast.

Data Only is one way out. Consider a customer who buys from a merchant five times a month, but only the one unusual purchase is sent for authentication. The issuer sees a stranger. Send the other four as Data Only and the issuer sees a regular customer, so when an unusual purchase does arrive, it can be judged in context.

Why payment teams are paying attention now

Visa’s Digital Commerce Authentication Program, or DCAP, adds a framework for consistent data contribution. Visa lists four required fields: device ID, IP address, email address and full billing address. Visa Data Only is one of several Intelligent Data Exchange integration paths, alongside token-service and API routes. DCAP and Data Only are related, but they are not interchangeable terms.

Visa’s Square case study illustrates the potential of richer data shared with issuers. Visa reports that Square’s enhanced-data transactions had approval rates 200 basis points higher than other card-not-present transactions, with fraud 29% lower. At the time of the report, Square was sending over 75% of its CNP traffic with enhanced data. These are Square’s reported results, not an expected return for every merchant.

A separate Visa and Adyen pilot used the Visa Secure data-sharing route for an enterprise travel merchant. It reported a 190-basis-point lift for U.S. domestic transactions among a subset of optimized U.S. issuers, while fraud remained stable. The analysis compared first-attempt approvals against a control group and excluded wallets, standard 3DS flows and merchant-initiated transactions.

Those results should inform a business case, with their study boundaries intact. They show that richer data can improve payment outcomes in specific deployments. They do not establish a universal Data Only uplift.

The cost conversation is changing too. Visa’s U.S. interchange schedule effective April 18, 2026 lists a 10-basis-point incentive for qualifying DCAP consumer-credit transactions in several categories, and 15 basis points when DCAP is combined with an EMV token. The higher rate for tokenized transactions reflects how the two work together: tokenization secures the credential, but it doesn’t tell the issuer who is using it, or whether that is their intent. That takes authentication and the context that travels with it. Eligibility and the applicable incentive depend on the transaction category and whether Visa’s DCAP and token requirements are met. These are gross interchange incentives, not guaranteed reductions in a merchant’s total processing bill.

Payment teams should ask their acquirer how incentives, enhanced-data fees and their own pricing model affect the net benefit. More approved legitimate sales and lower qualifying payment costs can strengthen the same business case, but each needs to be measured separately.

The U.S. opportunity and the European distinction

Data Only is not a Europe-only story. The U.S. is an especially relevant market for this discussion because payment teams can evaluate data sharing as an authorization optimization strategy in a market without the European SCA mandate.

Europe requires a different implementation conversation. Where strong customer authentication applies, a Data Only flow does not itself satisfy that requirement. A valid exemption or an out-of-scope transaction needs its own basis; additional data alone does not create an exemption. European Banking Authority (EBA) guidance states that SCA applies to payment initiation unless an exemption under the regulatory technical standards applies.

Availability also depends on the scheme, provider and market. CMSPI notes that Data Only requires a 3DS integration and that issuer adoption varies across markets. A global PSP should verify the actual scheme, processor and transaction eligibility for each market, including how data sharing fits with local authentication requirements.

What to ask your 3DS Server provider

For a merchant, the starting point is the segment of legitimate sales being lost to suspected-fraud declines. For a PSP or acquirer, the opportunity extends across a portfolio, but merchant categories and issuer responses will vary. I would begin with five questions:

• Which Data Only flows are supported for our schemes, processors and markets, and how is eligible traffic identified?

• Which useful data fields can we populate accurately, and how will we measure whether sharing that data improves authorization outcomes?

• How can we use Data Only alongside full authentication and applicable exemptions while keeping fraud rates within acceptable limits?

• Can we compare Data Only performance across issuers, markets and merchant segments to identify where it delivers the most value?

• What additional latency, processing fees and fraud exposure should be included in the business case?

Data quality matters as much as field availability. Wrong data can be worse than missing data: a device ID that changes every session, or an IP address that places a domestic shopper abroad, tells the issuer something that isn’t true. An empty field, inconsistent device identifier or unusable billing address will not deliver the same value as reliable context. The operational goal is to make relevant information usable in the issuer’s decision.

Measure the value on your own transactions

I would run a controlled pilot on eligible traffic and make first-attempt authorization approval rate the primary metric. Compare similar transactions, avoid counting retries as new customers, and break down the results by issuer, geography, merchant category and payment credential type. Keep fraud and chargebacks as guardrails, with enough time for losses to emerge. Read approvals, fraud and false declines together: optimizing any one of them in isolation pushes the cost into the others.

The economics should include additional approved sales, margin, processing costs and fraud losses. As an illustration, a one-percentage-point approval lift across one million comparable attempts means 10,000 additional approvals. At a $75 average order value, that is $750,000 in additional approved payment value before refunds, fees and losses. That calculation is an illustration, not an Entersekt forecast.

A phased rollout gives payment teams a way to expand where the data demonstrates value. PaymentsEd’s merchant education overview emphasizes issuer-specific routing and cautions against treating Data Only as an all-or-nothing strategy.

Make Data Only part of your 3DSS evaluation

Entersekt’s 3DS Server supports the merchant side of that strategy.

If suspected-fraud declines are costing your business legitimate sales, bring that problem into your next 3DSS evaluation. Ask your provider to explain the supported data-sharing flows, the eligible traffic and the evidence you will use to measure success.

Bring your target markets, current 3DS setup and suspected-fraud decline profile to a conversation with Entersekt. We can discuss how our 3DS Server fits your payment environment and what to evaluate for a Data Only rollout.

Explore further: Entersekt’s 3DS Server for merchants, acquirers, and PSPs.