3DS data-only

Most teams think of 3D Secure (3DS) as a trade-off. You get fraud protection and liability shift, and in exchange some customers hit a challenge screen at checkout. Where 3DS isn't mandated, like the US, plenty of teams look at that trade and decide it isn't worth it.

There's a version of 3DS that skips the trade-off entirely. It's called 3DS data-only. It uses the 3DS rails to send issuers rich device and customer data before authorization, but it never authenticates the customer. The goal isn't liability shift. It's getting more transactions approved.

If you've dismissed 3DS because of friction, data-only is worth a second look. In this post, we'll cover:

• What 3DS data-only is and why it exists

• The false decline problem it solves

• How the data-only flow works on Visa and Mastercard

• The benefits, including Visa's Digital Commerce Authentication Program (DCAP)

• Which transactions are eligible

• Where data-only fits in a broader 3DS strategy

• Its limitations, and how to measure whether it's working

TL;DR: 3DS data-only shares device, account, and customer data with the card network and issuer through the 3DS protocol, without challenging the customer. Issuers make better risk decisions, so fewer legitimate transactions are declined. In the US, Visa's DCAP program also pays a net 0.05% interchange incentive on eligible Visa consumer credit transactions that send the required data, rising to 0.10% with network tokens. There's no liability shift on fraud-related chargebacks, and it's only available where Strong Customer Authentication (SCA) isn't mandated.

What is 3DS data-only?

Data-only is a 3DS flow that sends enriched transaction, device, and customer data to the card network and issuer. It's always frictionless, because the customer isn’t being authenticated, so the issuer can't step up to a challenge. And because there is no customer authentication taking place, there is no liability shift for fraud-related chargebacks.

A full 3DS authentication does two things: it gives the issuer data, and it asks the issuer to verify the customer. Data-only only does the first part. The data travels over the same EMVCo 3DS infrastructure, and the network returns proof that the exchange happened. That proof goes into your authorization request, so the issuer has much more context when it decides whether to approve the transaction.

Data-only isn't a proprietary vendor feature. It's part of the EMV 3DS specification from version 2.2, and both major networks support it under their own names:

Why it was introduced

Merchants know a lot about their customers at checkout, and card networks want issuers to see that information too. For example, you know the customer's device, how long they've had an account, whether their shipping address matches their billing address, and whether they just changed their password. A standard authorization request passes almost none of this to the issuer.

Full 3DS was one way to close that gap, but it came with friction that many merchants outside SCA-mandated markets wouldn't accept. Data-only provides the data-sharing benefits without asking merchants to take on friction. Visa has since added a financial incentive to push adoption, which we'll cover below.

The problem: false declines

A false decline happens when an issuer rejects a legitimate customer with sufficient funds because it suspects fraud. It's lost revenue, and often a lost customer, since many shoppers don't retry after a decline.

False declines usually show up as one of two response codes:

• Do Not Honor (05): the catch-all code when the issuer's risk model isn't confident the transaction is legitimate.

• Suspected Fraud (59): the issuer's model has flagged the transaction as suspicious.

Every issuer runs its own risk model, and every model is only as good as the data it gets. Here's roughly what a standard card-not-present authorization request tells the issuer:

{
  "messageType": "0100",
  "pan": "4111111111111111",
  "expiryDate": "2027-09",
  "amount": { "value": 8999, "currency": "USD" },
  "merchant": { "id": "MID00293841", "name": "Acme Retail Co", "mcc": "5651", "country": "US" },
  "posEntryMode": "081",
  "eci": "07",
  "transactionType": "purchase",
  "recurring": false
}

{
  "messageType": "0100",
  "pan": "4111111111111111",
  "expiryDate": "2027-09",
  "amount": { "value": 8999, "currency": "USD" },
  "merchant": { "id": "MID00293841", "name": "Acme Retail Co", "mcc": "5651", "country": "US" },
  "posEntryMode": "081",
  "eci": "07",
  "transactionType": "purchase",
  "recurring": false
}

{
  "messageType": "0100",
  "pan": "4111111111111111",
  "expiryDate": "2027-09",
  "amount": { "value": 8999, "currency": "USD" },
  "merchant": { "id": "MID00293841", "name": "Acme Retail Co", "mcc": "5651", "country": "US" },
  "posEntryMode": "081",
  "eci": "07",
  "transactionType": "purchase",
  "recurring": false
}

That's the card, the amount, the merchant, and the fact that it's an online, customer-initiated purchase. There's nothing about who the customer is, what device they're on, or whether this looks like their normal behavior. With so little to go on, issuers are more conservative, and as a result good customers can get wrongly blocked.

How more data reduces false declines

Issuer risk models work by comparing a transaction against what they already know. A familiar device and IP address, an account that's been open for years, and matching billing and shipping addresses are all trust signals. A brand-new device in a new country, a password changed ten minutes ago, and a digital gift card shipped to a mismatched address are all risk signals.

Without that data, the issuer can't tell those two customers apart. With it, the issuer can approve the first with confidence and scrutinize the second. Data-only is how you get that data to the issuer on every eligible transaction, without adding friction.

How 3DS data-only works

A data-only request looks like a normal 3DS authentication request, flagged so the network knows not to authenticate. The network processes the data, returns a result, and you attach that result to your authorization request.

1. You send the data: Your 3DS server sends an authentication request containing device, account, and customer data, flagged as data-only.

2. The network validates it: The directory server checks the message conforms to the EMV 3DS specification and that it comes from a registered, certified 3DS server.

3. A risk assessment is generated: The transaction is scored against the data you sent and the issuer’s own signals, like how often that device or IP has transacted recently.

4. The result comes back: You receive an ECI value and a directory server transaction ID (and on Visa, a CAVV), which prove the data-only exchange took place.

5. You authorize: You include those values in your authorization request, and the issuer makes its decision with the extra context.

The customer sees none of this. There's no challenge and no redirect, just a small amount of extra latency from the additional network call.

What data is shared

Device, IP, and browser data can be captured automatically at checkout. The rest comes from your own systems, so you pass it in the request.

Visa vs. Mastercard

Both networks support data-only, and on both the data goes to the issuer's Access Control Server (ACS), the system that runs the issuer's 3DS risk checks. The main difference is money: only Visa offers you interchange rate discounts.

The benefits of 3DS data-only

Data-only has three benefits: higher acceptance rates, lower processing fees on eligible Visa transactions, and fewer fraud-related chargebacks.

Higher acceptance rates

This is the big one. When issuers have more data, they decline fewer good customers. Acceptance rate uplifts have been reported to be as high as 2.2% (source: Square) and even 4.6% for medium to high risk transactions (source: Worldpay).

Even a 2% uplift is significant. On $100M of annual card volume, it's around $2M of revenue that would otherwise have been declined.

Lower processing fees

In the US, Visa pays an interchange incentive on eligible transactions that send the right data through data-only. We cover the details in the DCAP section below.

Fewer fraud-related chargebacks

Data-only doesn't shift liability, so you are still liable for fraud-related chargebacks. But it does add a second check before that happens.

Your fraud model only sees your own customers and transactions. The issuer and the card network see activity across millions of cardholders and merchants. They may know a card was used fraudulently somewhere else yesterday, or that a device or email address has been linked to fraud before. The more data you send them, the more they can match against that history.

So when your model approves a payment it shouldn't have, the issuer gets a second chance to catch it and decline it, before it turns into a chargeback.

Visa DCAP: get transaction fee savings for sharing data

Visa Data Only is the 3DS flow that carries your data to the issuer. DCAP is an optional program, launched in the US on April 18, 2026, that pays you for using it. If an eligible transaction sends Visa's required fields through Visa Data Only, it gets a 0.05% interchange reduction.

A full 3DS authentication doesn't qualify for DCAP, even if it carries the same data. The two are separate flows, so you choose per transaction between liability shift (full 3DS) and the DCAP saving (data-only).

How the incentive works

The saving is calculated on the full transaction amount. Using a Visa network token alongside DCAP doubles the net saving, because Visa pays an additional 0.05% for tokenized transactions that also qualify for DCAP.

There are two things to check with your payment processor to make sure you receive these savings:

• Your pricing model: You'll only see the DCAP saving if your processor uses interchange-plus pricing, where interchange appears as its own line on your statement. If you pay blended pricing, meaning one flat percentage per transaction with no breakdown, your processor will probably keep the savings rather than pass it on to you.

• Whether the transaction qualifies for Visa's standard rates: Visa's lower interchange rates for well-formed transactions are called Custom Payment Service (CPS) rates. Visa's interchange schedule states that card-not-present incentives, including DCAP, require CPS qualification. A transaction that misses CPS requirements is "downgraded" to a higher rate and loses the DCAP saving. This usually happens because of how the payment was processed, for example capturing it too long after authorization, capturing a different amount, or missing address verification data. Your payment processor can tell you how much of your volume is downgraded.

What data DCAP requires

To qualify, every transaction must carry four fields:

• Device ID

• IP address

• Email address

• Phone number

• Full billing address (line 1, city, state, zip code, country)

Everything else in the data-only request is optional for DCAP, but still worth sending, since more data gives issuers more to work with.

Visa checks the data against its data quality standards. Transactions that don't meet them don't qualify for DCAP and may be subject to compliance enforcement.

Which transactions qualify for DCAP

Outside the US, Visa has announced DCAP for Canada is launching later in 2026.

Does the math work?

Evervault charges $0.03 per successful 3DS request. At a net 0.05% saving, DCAP covers that fee on any transaction of $60 or more.

Below the breakeven point, data-only is still worth running when the revenue from extra approvals outweighs the fee, which is worth testing against your own margins. Above it, every approved transaction is net-positive before you even count the uplift.

Other ways to send DCAP data

To qualify for DCAP, you send the required data through Visa Intelligent Data Exchange (IDX). Visa offers three ways in:

Visa Data Only sends the data through 3DS. It works with card numbers and network tokens, and because 3DS is an industry standard, the same integration also sends data-only requests on Mastercard.

• Visa Token Service only works for network token transactions.

• The Visa IDX API is a direct connection to Visa. It works with card numbers and network tokens.

If you already run 3DS, or plan to, data-only uses the same integration. You can also switch between data-only and full 3DS for each transaction.

What about Mastercard?

Mastercard supports data-only too, and it works the same way: the data goes to the issuer's ACS, there's no challenge, and there's no liability shift. What Mastercard doesn't offer is an interchange incentive like DCAP, so the case for Mastercard data-only is acceptance rates alone. Mastercard has also tightened its 3DS data requirements during 2026, so the data you collect for Visa DCAP is increasingly the data Mastercard expects too.

Which transactions are eligible for 3DS data-only?

3DS data-only works on Visa and Mastercard customer-initiated, card-not-present transactions where Strong Customer Authentication (SCA) isn't mandated. DCAP adds its own narrower rules on top, covered above.

When SCA is mandated

In the European Economic Area (EEA) and the UK, SCA is required on most online payments. Data-only doesn't authenticate the customer, so it can't satisfy SCA. Where SCA applies, you need full 3DS or a valid exemption.

SCA only applies when both sides of the transaction are in the EEA or UK: the merchant's acquirer and the customer's issuing bank. This is known as a two-leg transaction. When only one side is in the EEA or UK, it's a one-leg-out transaction, and SCA is applied on a best-effort basis rather than mandated.

What decides this is where the acquirer and issuer are, not where your company is headquartered. A US merchant that processes a German customer's German-issued card through a European acquirer is running a two-leg transaction, so SCA applies and data-only isn't an option. The same US merchant processing that card through a US acquirer is one-leg-out, so data-only is available.

Where data-only fits in your 3DS strategy

Data-only works best as one option among several, chosen per transaction based on how confident your fraud model is. It's not a replacement for full 3DS.

We understand why many teams are wary of 3DS. The first version was slow and redirect-heavy, and its reputation for hurting conversion stuck. Modern 3DS is very different. In our own US data, 74% of 3DS transactions were frictionless, higher than in the UK or Germany, where 3DS has been mandatory for years. But if friction is still your priority, you don't have to choose all or nothing.

Here's how the options fit together, from least to most friction, for transactions that fall outside SCA scope.

A few examples of how this plays out:

• A subscription app sends returning, logged-in customers through data-only, and runs full 3DS on first purchases from new accounts, where account-takeover and card-testing risk is highest.

• An online travel agency uses fail-on-challenge on most bookings to pick up liability shift without friction, but runs full 3DS on high-value, last-minute bookings, and data-only on repeat bookers with a clean history.

• A marketplace starts with data-only on all eligible US Visa traffic to capture DCAP, then introduces full 3DS for the segments its fraud team flags.

The common thread is that your own fraud model decides, and 3DS gives you three different levers instead of one.

Limitations, and how to measure whether it's working

The biggest limitation of data-only is that not every issuer uses the data. You can send a rich request to an issuer whose model ignores it, and pay for nothing.

Issuer utilization varies

Issuers and their ACS providers don't all configure their risk models to use data-only signals as inputs. Some weigh them heavily, some barely at all.

The fix is to measure by issuer rather than in aggregate:

1. Run a holdout: Send a random slice of eligible traffic through data-only and keep a control group on standard authorization.

2. Track specific decline codes: Compare Do Not Honor (05) and Suspected Fraud (59) rates between the two groups. These are the codes data-only is meant to move, so they give a cleaner signal than overall approval rate, which is affected by insufficient funds, expired cards, and other declines that data can't fix.

3. Break results down by issuer or BIN range: Keep data-only on for issuers where it lifts approvals, and turn it off where it doesn't.

4. Re-test regularly: Issuer’s update their models, often under pressure from large merchants and acquirers. An issuer that ignores the data today may use it in six months.

You need enough volume per issuer for the comparison to be meaningful, so start with your largest issuers.

Data quality decides the outcome

Partial or placeholder data can disqualify a transaction from DCAP, and it gives issuers a weaker signal. Audit what you actually collect at checkout, especially full billing addresses and verified email addresses, before switching data-only on broadly.

Added network calls

Data-only is invisible to the customer, but it does add a request before authorization. Monitor latency at checkout, especially on mobile.

There's no liability shift

If a fraudulent transaction is approved after data-only, the chargeback is still yours. Where liability shift matters, use full 3DS or fail-on-challenge.

How 3DS data-only works with Evervault

Evervault supports 3DS data-only on Visa and Mastercard. You request it with a single setting when you create a 3DS session, and because there's no challenge, you don't need to add anything to your front end. Data-only and full 3DS both run through the same integration, so you can choose per transaction. You only pay for successful requests, and our solution is fully standalone, so it works across all PSPs.

Frequently Asked Questions

Does 3DS data-only shift fraud liability?

No. Data-only doesn't authenticate the customer, so fraud-related chargeback liability stays with the merchant. For liability shift, you need a full 3DS authentication.

Does 3DS data-only add friction for customers?

No. Data-only is always frictionless. The issuer can't request a challenge, and the customer doesn't see any extra step.

Do I need 3DS data-only for Visa DCAP?

3DS data-only is the most common way to qualify for DCAP, and it works for both card numbers and network tokens. Visa also accepts DCAP data through Visa Token Service (network tokens only) and the Visa IDX API (Visa transactions only).

How much can Visa DCAP save?

A net 0.05% of the transaction amount on eligible US Visa consumer credit transactions, or 0.10% when combined with a Visa network token.

Is Visa DCAP available outside the US?

DCAP launched in the US in April 2026, and Visa has announced it for Canada. Check with your acquirer for other regions.

Can I use 3DS data-only in Europe or the UK?

Only on one-leg-out transactions, where either the acquirer or the issuer is outside the EEA or UK. When both are inside, SCA is mandated and data-only can't be used.

Does Mastercard offer an incentive for data-only?

No. Mastercard supports data-only, which shares data with the issuer to improve approval rates, but it doesn't pay an interchange incentive like Visa's DCAP.

How much does 3DS data-only improve acceptance rates?

Published figures range from about 2.2% to 4.6%. Results vary by issuer, so measure the uplift on your own traffic.

The most overlooked way to reduce false declines

3DS data-only is one of the few payment optimizations with no customer-facing trade-off. It gets more transactions approved, can cut Visa processing costs and helps issuers catch fraud your own model missed. All of it runs in the background of a checkout your customers already use.

It's often overlooked because it sits under the 3DS label, and many teams outside Europe stopped evaluating 3DS years ago. With Visa now paying merchants to share this data, that's worth revisiting.

Frictionless 3DS, on any PSP

Run data-only, fail-on-challenge, and full 3DS from one integration, and choose per transaction. Explore Evervault 3DS.