Stop Hard Coding Your 3DS Challenge Preference

Somewhere in almost every merchant’s payment integration there is a single field, set once at go-live and never looked at again, that quietly shapes the checkout experience of every customer who follows. It is the 3DS challenge preference, the signal you send to the cardholder’s bank saying how you would like the authentication to go. Most merchants hard code it. Many hard code it to “challenge requested” for everything, on the reasoning that more friction must mean more protection.

That reasoning deserves a closer look, because a preference set for your riskiest transaction is being applied to your safest one too. This article covers what the two authentication flows actually do, what the liability shift does and does not buy you, where a challenge is a regulatory requirement rather than a choice, and how to set the field per transaction based on your own risk appetite.

Challenge vs frictionless: what actually happens

When a card payment goes through 3DS, there are two ways the authentication can play out.

In the frictionless flow, the issuer makes its decision silently. Your authentication request carries a rich set of data about the cardholder, their device, and the transaction, and the issuer’s risk engine uses it to decide if the customer is who they say they are without asking them anything. The customer never knows authentication happened. From their side, the payment just works.

In the challenge flow, the issuer steps the customer up. They are asked to prove themselves, typically by approving a push notification in their banking app, entering a one-time passcode, or passing a biometric check. Done well it takes seconds. Done badly, or at the wrong moment, is where checkout flow fails: challenge steps are a known point of drop-off, particularly for customers on older devices or with banks whose challenge screens are clunky.

The important point is that the issuer decides which flow applies, but as a merchant you get a say. The EMV 3DS protocol includes a challenge preference field (the 3DS Requestor Challenge Indicator) through which you can ask for no challenge, express no preference, or actively request one. The issuer is not obliged to honour it, but in practice your preference carries real weight in the decision. What you should ask it for depends on what each flow actually buys you, which is where the liability shift comes in.

The liability shift: what you are actually buying

The commercial reason merchants love a challenge is the liability shift. When a transaction is successfully authenticated through 3DS, liability for fraud chargebacks moves from you to the issuer. If the cardholder later claims the payment was unauthorised, that dispute lands on the bank’s desk rather than yours.

Here is the part that gets missed: the liability shift applies to successful authentication through either flow. A frictionless approval carries the same fraud liability protection as a completed challenge. You do not need to put the customer through a step-up to get it. The main situation where a frictionless transaction does not shift liability is when you have asked for an exemption from authentication, for example a transaction risk analysis or low-value exemption, in which case the liability stays with you as the price of skipping SCA.

It is also worth remembering what the shift covers. It protects you against fraud chargebacks, the “this wasn’t me” disputes. It does nothing for first-party misuse, service disputes, or a customer who simply wants their money back. If your chargeback problem is not a fraud problem, forcing challenges will not fix it.

Recurring setup: the one place a challenge is mandatory

There is one place where requesting a challenge is not a preference but an obligation. Under PSD2, Strong Customer Authentication is required when a customer sets up a recurring payment or stores a card for future merchant-initiated use. The regulation requires SCA at the point the mandate is given; the subsequent merchant-initiated transactions are then out of scope of SCA entirely, provided the authority was properly authenticated when first given or amended.

The protocol has a value for exactly this. Challenge indicator 04, “challenge requested: mandate”, tells the issuer a regulatory requirement applies and a challenge must be performed. In the Acquired API this is challenge_mandated, passed in the challenge_preference field of the payment request. For a lender setting up monthly repayments on a new agreement, or a collections firm establishing a repayment plan, that first authentication should always be sent with the mandate flag. Get it right and every subsequent instalment can run as a merchant-initiated transaction with no SCA at all, which is precisely the outcome you want for a book of recurring repayments.

Regulators are increasingly checking that the chain holds. France offers a preview of the direction of travel: since 2025 its banking supervisor has enforced PSD2 strictly, including controls on merchant-initiated transactions that require the series to trace back to a properly authenticated mandate, with hard declines for traffic that cannot. If your recurring collections rely on mandates set up years ago, or migrated from another provider, it is worth confirming that the original SCA evidence is intact and referenced correctly, because other markets tend to follow where enforcement leads.

The hard coding problem

Now put those pieces together and look at what a hard coded “always challenge” preference actually does. It applies mandate-level friction to every transaction, regardless of who the customer is, what they are paying, or what you already know about them. The protection it buys, the liability shift, was mostly available frictionlessly anyway. What it costs is conversion, and in some portfolios that cost is severe.

Consider two transactions a lender might see on the same afternoon. The first is a borrower eighteen months into an agreement, paying the same amount they pay every month, from the same device, ahead of a payment plan they have never missed. The second is a brand-new customer making an unusually large one-off settlement from a device you have never seen. Does it make sense that both receive an identical authentication experience? The first customer is about as low-risk as card payments get, and every challenge you put in front of them is a fresh opportunity for a payment that would have completed to fail. The second is exactly the transaction the challenge flow was built for.

For collections firms the stakes are sharper still. A customer who has finally engaged and is trying to make a payment towards an arrears balance is a fragile moment of intent. A failed one-time passcode, a banking app they have not set up, a challenge screen that times out: any of these can end the interaction, and they may not come back.

Soft code it: match the challenge to the risk

The better approach is to treat the challenge preference as a decision, made per transaction, based on your risk appetite. You already hold the signals: is this a known customer or a new one, does the amount fit their history, is the device recognised, is this a scheduled repayment or an out-of-pattern one-off? A simple rules layer mapping those signals to the challenge indicator gets you most of the value. Known customer, expected amount, recognised device: request frictionless and let the issuer’s own risk engine be the backstop. New customer, high value, or anything that trips your own fraud rules: request the challenge and take the strong authentication gladly. Mandate setup: always flag the mandate.

One caveat: do not just request, justify. A frictionless preference is a claim you are making about the transaction, and issuers judge the claim by the evidence sent alongside it. A no-challenge request arriving with thin or sloppy data, a placeholder email, your server’s IP instead of the customer’s, a phone number with no country code, reads to an issuer’s risk model as more suspicious rather than less, and can attract exactly the step-up you were trying to avoid. The preference and the data have to travel together: send the frictionless request on the back of complete, accurate cardholder and device data and the issuer has a reason to agree with you. We covered what that data set should look like in our article on making the most of Mastercard’s Enhanced Data Standards, and the same principle applies across schemes.

Setting it through Acquired

If you process through Acquired, the challenge preference is set per transaction in the tds object of the Process a payment request, via the challenge_preference field. It takes four values:

challenge_preference	What it tells the issuer	When to use it	Liability shift
no_preference (default)	You have no view; the issuer’s risk engine decides the flow	When you have no risk signal either way	Yes, on successful authentication through either flow
no_challenge_requested	You would prefer the customer is not challenged	Known customer, expected amount, recognised device	Yes, if the issuer authenticates frictionlessly. If you separately request an SCA exemption, liability stays with you
challenge_preferred	You would like the customer stepped up	New customer, high value, out-of-pattern transactions, anything tripping your fraud rules	Yes, on a successfully completed challenge
challenge_mandated	A challenge is required by regulation	Recurring payment or mandate setup, storing a card for future merchant-initiated use	Yes, on a successfully completed challenge

The issuer always makes the final call, so no_challenge_requested is a preference rather than a guarantee, and an issuer can still step up a transaction you asked to keep frictionless. But the field is read, and sending a considered value per transaction is how you put your own risk knowledge to work.

None of this requires machine learning or a fraud team of twenty. It requires deciding that one static field should not make the same call for your safest customer and your riskiest one. If you want to review how your integration is currently setting its challenge preference, or to start passing a per-transaction value, the Implementations team can walk you through it.

---

Sources and references

• Acquired.com API Reference, Process a payment, for the tds.challenge_preference field and its allowed values.
• EMVCo, EMV 3-D Secure specification, which defines the 3DS Requestor Challenge Indicator value set, including 04 (challenge requested: mandate), and the frictionless and challenge flows.

---

Disclaimer: This article is general information about payment authentication and does not constitute legal, regulatory or compliance advice. Acquired does not advise on, ensure or guarantee your compliance with PSD2, SCA or any other regulatory obligation; you remain responsible for your own compliance and should take your own professional advice.