SCA & 3DS for travel: exemptions without lost sales.

In the EU and UK, strong customer authentication (SCA) is the law for most online card payments, and 3-D Secure is how it's usually delivered. Done crudely, it throws a challenge screen at every guest and bleeds bookings. Done well, most legitimate payments never see a challenge at all.

The thirty-second primer

PSD2 and its regulatory technical standards require two of three factors — something the customer knows, has, or is — for electronic payments, with a defined list of exemptions. 3DS2 is the protocol that carries this: it ships rich transaction data to the issuer, who then decides to approve silently (a frictionless flow) or challenge the cardholder. The quality of the data you send materially changes how often issuers challenge.

The exemptions that matter for bookings

• Transaction risk analysis (TRA). Low-fraud acquirers can request exemptions up to value thresholds that step with fraud rates. This is the workhorse: it rewards clean traffic with frictionless flows — and it's an argument for keeping your acquirer's fraud numbers pristine.
• Low-value. Small amounts can skip SCA within counters set by the rules. Useful for ancillaries and add-ons, less so for a charter deposit.
• Merchant-initiated transactions (MIT). The travel heavy-lifter. When a saved card is charged later without the customer present — the balance payment weeks after a deposit, a no-show fee under agreed terms — a properly flagged MIT is out of SCA scope, provided the mandate was authenticated up front.
• One leg out & MOTO. Payments where the issuer or acquirer sits outside the EEA/UK, and mail/telephone orders, sit outside SCA scope — relevant for global travel mixes with US and other international cards.

The pattern for delayed travel payments: authenticate once at booking, then run later captures and balance payments as properly flagged MITs.

Why travel needs orchestration, not a checkbox

Every exemption is a decision with a trade-off: request an exemption and (if granted) lose the liability shift that full 3DS gives you; challenge everyone and watch conversion drop. The right answer differs by amount, corridor, card type, issuer behaviour and how far away the trip is. That's a per-transaction decision engine — exemption strategy, issuer data enrichment, fallback logic when a 3DS flow breaks — not a static setting in a dashboard.

It also has to fail gracefully: soft declines that ask for authentication should trigger an automatic 3DS retry, not a lost booking; challenges should arrive on the device the guest is actually holding.

What good looks like in numbers

Teams that treat authentication as a product track four things: frictionless share, challenge success rate, exemption grant rate, and fraud-vs-liability balance per corridor. If your provider can't show you these per issuer and per exemption type, you're flying the most conversion-sensitive part of checkout blind.

Where Veloqen stands

Authentication orchestration is core product in our platform — exemption logic, issuer intelligence and fallback flows tuned for delayed-delivery verticals, with the booking lifecycle (deposits, balances, MITs) as a first-class concept. The travel-specific view is on our travel page, and the pricing consequences of better authentication — lower fraud costs, fewer lost sales — are part of any quote conversation.