Stop running 3DS on every transaction

A lot of payment teams run 3D Secure on every card transaction. It's the simplest way to stay on the right side of strong customer authentication rules, and it means your best customers go through the same checks you built for fraudsters.

If you’re running payments, fraud, or are a product lead selling in SCA regions or at high volume, this post is for you. It walks through a flow where the fraud score decides when 3DS runs, and the 3DS workflow video shows it end to end.

Blanket 3DS is a decision nobody revisits

You’ll find that, quite often, checkout stacks split the work across three tools. A fraud provider scores the transaction, a 3DS server handles authentication, and the gateway sends the authorization. Each one sees its own piece of the payment and nothing else.

So the fraud tool knows a returning customer is low risk, and the 3DS step isn’t aware of that. It challenges them anyway. Then the gateway gets an authorization request with none of that context attached.

The logic tying those steps together usually lives in application code. The thresholds get set at launch, and moving one means an engineering ticket and a spot in the sprint. In our Composer launch post, we put the cost plainly: teams spend six to twelve months building payment logic that turns brittle and expensive to maintain.

If changing a 3DS rule takes a sprint, the rule never gets tuned. Challenging everyone is the cheapest option for engineering, and the bill lands on conversion.

Skipping 3DS isn't an option in SCA regions

In the EEA and the UK, most remote card payments need strong customer authentication. Turning 3DS off isn't the fix. Running it only when the transaction calls for it is.

The rules already make room for that. The PSD2 RTS carves out exemptions, including:

• Low value: payments up to €30, until five in a row or €100 in total have gone through without authentication.
• Transaction risk analysis: payments up to €100, €250, or €500, as long as the payment provider's fraud rate stays under 0.13%, 0.06%, or 0.01% respectively.
• Trusted beneficiaries: merchants the cardholder has added to an allowlist with their bank.

Those exemptions only pay off if something decides when to ask for them. That something should be the risk score. We cover how each one works in our guide to SCA exemptions.

Score first, then decide whether 3DS runs

The fix is to put the fraud check in front of 3DS and let the result pick the path.

1. Score the transaction with a fraud provider or your own internal score.
2. Low risk: skip the challenge and go to authorization, requesting an exemption where the rules allow it.
3. Medium risk: run frictionless 3DS. The issuer gets the device and transaction data and approves without asking the cardholder anything.
4. High risk: run the full 3DS challenge, then authorize or decline.

Your good customers get through checkout without a pause. The risky ones still meet a challenge, and the ones that look like fraud never reach the gateway.

Liability and friction go their separate ways

When a transaction is successfully authenticated with 3DS, fraud chargeback liability generally shifts to the issuer under card network rules. That's the protection you give up when you skip it.

An exemption cuts the friction, and the merchant keeps the fraud liability. So every threshold is a call about where you'd rather carry risk. A large order from a new customer is worth authenticating. A small repeat order from a five-year customer probably isn't.

That's a commercial decision about margin and risk appetite. It belongs with the people who own those numbers, not in a backlog.

What changes in Composer

In Composer, the fraud score and the 3DS step sit on one canvas, so the score decides whether 3DS runs. Your business team changes the risk thresholds and which step fires. Changes take effect on the next transaction, with no deploy.

Engineering does the setup once. They connect the Composer server SDK and your tokenization method. Cards get vaulted first, and Composer works with the token from there.

The 3DS step handles exemptions and liability shift. It works with 3DS2 Global and the gateways you already use, so there's no 3DS rebuild.

Already running 3DS? Good. The question is whether it fires on the right transactions, because that's what moves auth rates.

Three questions for your next payments review

What share of your transactions go through 3DS today? How much of your volume sits in SCA regions? And what does it take to change your 3DS trigger logic?

If that last answer involves a sprint, you're probably challenging more customers than you need to. Watch the 3DS workflow, or talk to us about your 3DS logic.