3RI for Travel Bookings: Authenticating Once on Behalf of Multiple Merchants

A cardholder books a flight, a hotel, and a rental car in a single checkout on a travel site. Three merchants will each submit their own authorization against that card. Only one of them, the travel site, ran the 3DS authentication.

For a period, the card schemes gave the industry a way to handle this: authenticate once, and let that same authentication cryptogram be reused across multiple merchant authorizations tied to the same booking. That wasn't a workaround merchants invented. It was explicit scheme guidance, built specifically for split shipments and multi-party travel bookings, and it worked.

It was also never meant to be permanent. Visa, for one, capped the reuse at a fixed number of authorizations per booking and described the recommendation itself as a bridge, something to lean on while 3RI support matured across the industry, not a long-term feature. That's the part worth understanding before deciding what to build: the recommendation was a stopgap by design, and 3RI, an EMVCo specification adopted across the schemes, was always the intended destination.

What a Booking Agent Actually Is

"Booking agent" isn't limited to online travel agencies. Across the schemes, the term covers any party that runs the authentication on behalf of a merchant that will process its own authorization: an OTA, a traditional travel agency with a booking site, a travel management company, or a larger supplier taking a booking for a partner, an airline handling a reservation on behalf of a franchised hotel, for instance.

If a booking agent is handling checkout for exactly one merchant that collects the entire payment, there's nothing to solve here: one authentication, one cryptogram, one merchant using it, done. The reuse recommendation, and now 3RI, exist for the moment a single checkout covers more than one merchant of record.

The Multi-Merchant Case: One Checkout, Several Merchants of Record

This is the scenario 3RI is built for. A cardholder completes one checkout, but the components of that booking are collected by different merchants, each of whom will run its own authorization later, sometimes on a different day, sometimes only if a specific condition is met.

Instead of stretching one cryptogram across several merchants, the booking agent authenticates the cardholder once, then goes back to the issuer afterward, on its own initiative, and requests a separate cryptogram for each merchant that needs one, each carrying that merchant's own name. Under Visa's implementation this uses indicator value 11 in EMV 3DS 2.2 (or 16 under the Bridging Message Extension). Mastercard documents the same scenario as its own "Agent Payment" use case within Identity Check. No cap on how many merchants can be covered, no regional limit, and no second prompt to the cardholder.

Take a booking with three parts: a $340 flight payable to the airline at booking, a $150 hotel stay, and a $75 rental car deposit. The booking agent authenticates once, for $565, the sum of all three amounts. Then it submits three separate 3RI requests, one per merchant, each carrying that merchant's own name combined with the booking agent's: $340 for the airline, $150 for the hotel, and $75 for the rental company.

‍

Under the reuse recommendation, all three merchants would have authorized against the same $565 credential, named for the booking agent, up to the allowed number of reuses. Here, each merchant authorizes against a cryptogram that names it specifically instead, with no cap on how many merchants the booking can cover.

Each merchant only ever sees its own share of the total. The airline's cryptogram is scoped to $340, the hotel's to $150, the rental company's to $75, and none of the three can be used to authorize more than the amount named in its own request. Add them up and they equal the amount the cardholder actually authenticated, no more.

The Naming Rule That Makes This Work

Each 3RI request needs to combine the booking agent's name with the specific merchant's name, so the cryptogram that comes back points to the right party downstream. This is the structural piece the reuse recommendation could never offer, since a single reused cryptogram could only ever carry one name, the booking agent's. Visa's own guidance is clear that a mismatch between merchant names, IDs, or amounts across authentication and authorization isn't automatically a red flag, legitimate reasons for these differences exist, including the booking agent scenario itself. But naming each 3RI request correctly is still what lets each merchant's authorization line up cleanly with its own credential rather than an inherited one.

The Amount Rule Issuers Actually Enforce

Issuers reconcile 3RI amounts against the original authentication, but the rule is one-directional, not exact. The sum of the 3RI requests has to stay under the original authenticated amount. It doesn't have to equal it.

That matters because not every merchant in a booking will always draw the full amount named in its 3RI request, or request one at all if it isn't charging anything yet. A merchant that never bills its portion simply leaves that part of the authenticated total unused. That's a normal outcome, not a discrepancy an issuer should flag.

Currency adds one more wrinkle worth knowing: a merchant can authorize in a different currency than the one used at authentication, as long as the converted amount stays under what was authenticated. On Visa, this is checked against Visa's own currency conversion reference file. A US booking agent authenticating a European hotel is the common version of this.

What This Means If You're Still Relying on Reuse

If your multi-merchant bookings are still built around one reused cryptogram, that's not a design flaw, it's what the industry was explicitly told to do for a period, across more than one scheme. What none of the schemes told merchants is that this would stay the answer. Visa scoped its version of the recommendation to Europe and capped it at a fixed number of merchants per booking precisely because it wasn't meant to carry every use case indefinitely, only to buy time while 3RI support caught up across the ecosystem.

The actual work here isn't a policy change, it's a 3DS Server configuration change: one 3RI request per downstream merchant, named correctly, amount-capped against the original authentication. That scales to any number of merchants, works outside Europe as well as inside it, and doesn't depend on scheme-specific guidance that was always going to be temporary.

Two related scenarios are worth their own treatment rather than a paragraph here: the single-merchant baseline case where no 3RI is needed at all, and the case where the booking agent is itself one of the merchants of record and only needs 3RI for the others. Both are coming in upcoming pieces.