Configure 3D Secure Exemptions for Better Approvals

A payment flow that challenges every customer is not automatically safer. It can create avoidable checkout abandonment, particularly for repeat buyers and mobile users. To configure 3D Secure exemptions effectively, merchants need more than a switch in a gateway dashboard: they need transaction-level rules that balance conversion, issuer expectations and fraud exposure.

For European card payments, Strong Customer Authentication (SCA) remains the default under PSD2. Exemptions are the controlled exceptions. Used well, they allow qualifying transactions to proceed without a customer challenge while preserving the option to authenticate when risk, transaction value or issuer policy requires it.

What 3D Secure exemptions actually do

An exemption is a request made within the payment flow, usually by the acquirer or merchant through its payment gateway, asking for SCA not to be applied to a qualifying transaction. The issuer makes the final decision. A transaction can therefore be eligible for an exemption, correctly flagged by the merchant, and still be challenged by the cardholder’s bank.

That distinction matters operationally. Exemptions should be treated as a way to improve the probability of a frictionless approval, not as a guarantee that authentication will be bypassed. Your integration must support both outcomes without disrupting the customer journey.

When an issuer accepts an exemption, liability treatment depends on the exemption type and the applicable scheme rules. When an acquirer applies Transaction Risk Analysis (TRA), for example, the acquirer generally assumes fraud liability. That is why exemption configuration belongs alongside fraud strategy, chargeback monitoring and acquiring management, rather than solely within checkout design.

Configure 3D Secure exemptions by transaction type

The strongest approach starts with classification. Do not apply a single rule across all card transactions simply because they appear low risk. A low-value one-off retail order, a recurring subscription renewal and a travel booking for a future date have different fraud signals, fulfilment profiles and dispute risks.

Separate customer-initiated and merchant-initiated payments

Customer-initiated transactions occur when the cardholder actively pays at checkout. These are the primary transactions considered for SCA and exemption requests. Merchant-initiated transactions (MITs), such as a subsequent subscription collection or a delayed charge under an agreed mandate, are generally outside SCA scope when they follow a properly authenticated initial agreement.

The initial payment or mandate setup must be correctly flagged, authenticated where required and stored with the relevant reference data. If the original setup is incomplete, later recurring collections may fail, be treated as customer-initiated transactions or generate issuer queries. For subscription, telecoms and hospitality businesses, this implementation detail has a direct effect on revenue continuity.

Use low-value exemptions carefully

Low-value exemptions can be requested for transactions of up to EUR 30, subject to cumulative issuer limits. An issuer may require SCA after five consecutive exempt payments or when the aggregate value of exempt payments reaches EUR 100 since the last successful authentication.

This makes low-value exemptions useful for genuinely small baskets, but not a universal answer for microtransactions. The issuer maintains the counters, so merchants should expect occasional challenges even when their own transaction history appears eligible. Build the checkout to handle this normally rather than treating it as an error.

Apply TRA only where your risk data supports it

TRA exemptions are designed for transactions that fall within defined value thresholds and are assessed as low risk by the acquirer. The permitted thresholds are linked to the acquirer’s reported fraud rate: up to EUR 100, EUR 250 or EUR 500, depending on the applicable level.

TRA can reduce friction at meaningful basket values, but it is not a reason to relax fraud controls. Acquirers and payment providers will assess factors such as device signals, payment history, velocity, identity consistency, IP reputation, delivery risk and merchant fraud performance. High-risk verticals may need tighter rules, even where a transaction technically qualifies.

A practical configuration is to request TRA only when the transaction satisfies both the acquirer’s eligibility criteria and your own risk score. For example, a returning customer using a previously successful card, with consistent device and location signals, may be suitable. A first-time buyer placing a high-value, express-delivery order with mismatched data is unlikely to be a sensible candidate.

Treat trusted beneficiary status as issuer-led

A cardholder can add a merchant to their bank’s trusted beneficiary list, sometimes called whitelisting. Future payments to that merchant may then be processed without SCA. This is valuable for returning-customer experience, but it is controlled by the issuer and cardholder, not configured as a blanket merchant preference.

Your role is to ensure that your 3D Secure implementation passes the correct merchant identity and transaction data, giving the issuer the information it needs to make a reliable decision. Inconsistent merchant descriptors or poor data quality can undermine that confidence.

Set exemption rules in the right order

Exemption logic needs an order of precedence. Without it, a payment request may be sent with contradictory indicators or routed through an acquirer that cannot support the selected approach. Payment orchestration is especially valuable for merchants operating across multiple acquirers, currencies and markets because exemption support and risk appetite vary by route.

A sensible decision flow is to first identify whether the transaction is out of scope for SCA, such as a valid MIT. Next, identify whether a specific exemption applies, such as low-value or TRA. Then assess whether the selected acquirer, card scheme, issuer region and transaction value support that request. If not, initiate 3D Secure rather than sending an ambiguous authorisation request.

Do not use exemptions to conceal weak transaction data. Submit complete 3D Secure v2 data wherever possible, including billing and delivery details, customer account age, previous transaction history and device information. Rich data supports issuer risk assessment whether the issuer grants a frictionless authentication, accepts an exemption or decides to challenge.

Build a fallback path for issuer decisions

The most damaging exemption configuration is one that turns a soft decline into a lost sale. If an issuer declines an exemption request and indicates that authentication is required, your payment flow should be able to retry with 3D Secure promptly and without forcing the customer to re-enter card details.

This fallback should be tested for every major card route. Confirm how your gateway surfaces soft-decline responses, whether it automatically triggers an authentication retry, and which transaction fields must be preserved. The correct response handling is often the difference between a recoverable authentication step and an unnecessary abandonment.

For mobile checkout, keep the hand-off to an issuer app or browser challenge clear and stable. Customers should understand that their bank is confirming the payment, not that the merchant has failed to process it. A vague error message at this point can turn a legitimate security control into a support ticket.

Monitor results by issuer, acquirer and payment use case

Approval rate alone does not tell you whether exemption strategy is working. An apparent uplift may be offset by increased fraud, higher soft-decline rates or a shift in traffic towards transactions that issuers later challenge. Review performance by exemption type, transaction value, country, issuer, card scheme, customer cohort and acquirer route.

Monitor at least four connected outcomes: frictionless and challenged 3D Secure rates, authorisation approval rates, fraud and chargeback rates, and soft-decline recovery. For recurring commerce, also track renewal success after mandate setup. A rule that improves first-payment conversion but weakens renewal performance is not commercially successful.

Rules should be reviewed after changes in fraud patterns, new market launches, acquirer migrations or material shifts in average order value. Travel, gambling and digital services can see rapid changes in transaction behaviour, so static exemption settings rarely remain optimal for long.

Align technical configuration with acquiring strategy

The gateway can pass exemption requests and transaction data, but the quality of outcomes depends on the full payment chain. Your acquirer must support the relevant exemption types, maintain acceptable fraud performance and provide clear response data. Your fraud platform must produce decisions quickly enough for checkout. Your integration must handle authentication retries cleanly.

For complex payment estates, configure rules centrally and apply them consistently across hosted payment pages, API integrations, payment links and recurring billing flows. AllSecure can help merchants align gateway controls, acquirer routing and 3D Secure v2 data so that exemption decisions support both acceptance and risk policy.

The right target is not the lowest possible challenge rate. It is a payment flow that challenges the transactions that need it, protects the transactions that qualify for frictionless processing and gives customers a dependable route to completion when an issuer asks for more proof.