3RI for Delayed Shipments: Refreshing Liability Protection Without the Cardholder

A cardholder orders a made-to-order sofa. It won't ship for five months. The merchant authenticated that cardholder at checkout, the same day the order was placed. By the time the sofa actually leaves the warehouse, that authentication is no longer doing what it was meant to do.

Visa's guidance treats an authentication as carrying liability protection for a bounded window, 90 days. Inside that window, the cryptogram from the original authentication backs the eventual authorization cleanly. Outside it, the merchant is shipping against a credential that no longer covers the transaction the way it did on day one, even though nothing about the original authentication was done incorrectly.

Before 3RI existed, there wasn't a clean way to close that gap short of getting the cardholder to authenticate again, often not realistic months after checkout, or shipping without protection and accepting the exposure. 3RI, introduced as part of EMV 3DS 2.1 and extended in 2.2, gives merchants a third option: go back to the issuer before the original window closes and request a fresh cryptogram for the same order, without the cardholder coming back into the flow at all.

What Counts as a Delayed Shipment

This use case covers any order where the goods or service won't be delivered within the original authentication's protection window: custom-made or made-to-order goods, pre-orders and waitlisted items, seasonal or backordered stock, services scheduled well in advance, and travel booked far enough ahead that the trip itself falls outside the window.

If the order ships within that window, there's nothing to solve here: the original cryptogram still carries protection, and the merchant authorizes against it as usual, done. The delayed shipment case, and the reason 3RI exists for it, only shows up once the gap between authentication and delivery is expected to run longer than the window allows.

Refreshing Protection Without the Cardholder

The mechanics are a request, not a re-authentication. The merchant submits a 3RI request referencing the original authenticated session, using indicator value 06 in EMV 3DS 2.2 (or 15 under the Bridging Message Extension), and the issuer returns a new cryptogram carrying its own fresh protection window. The cardholder isn't prompted, isn't redirected, and doesn't know the request happened.

Visa's guidance is specific about timing: merchants should submit the refresh request within the original window, but as late in that window as practical, rather than immediately after checkout. Waiting keeps the authentication closer to the point where the goods actually move, and it matters more than it might seem for orders with long or uncertain lead times, since a merchant may need to repeat the refresh more than once if a delay stretches past even the extended window, a booking made years in advance being the clearest example.

Take an order for a $980 made-to-order sofa, placed today with a five-month lead time. The merchant authenticates the cardholder for the full $980 at checkout but doesn't charge anything yet, since nothing has shipped. Near the end of the original window, the merchant submits a 3RI request referencing that original session and receives a refreshed cryptogram. When the sofa finally ships, the merchant authorizes using that refreshed credential instead of the original one.

Not every delayed order works this cleanly in one piece. An order can just as easily split into a deposit taken now and a balance delayed later, in which case only the delayed portion needs a refreshed cryptogram, the same way the sofa example above only needed one because nothing was charged upfront.

The Reference Rule That Makes This Work

A 3RI request for a delayed shipment isn't a fresh, unconnected authentication. It has to carry specific details from the original session: the prior authentication method, the timestamp of that original authentication, and the original ACS transaction reference. Together, those let the issuer verify the refresh actually traces back to a real prior authentication rather than treating it as a request with no history behind it.

The 3DS Requestor Name and Merchant Name also have to match between the initial authentication and every 3RI request tied to it. An expired original cryptogram no longer carries liability protection once its window has closed, but Visa's guidance notes issuers can still treat it as evidence that authentication happened in the first place, which is part of why keeping that reference intact matters even after the original credential has aged out.

The Amount Rule Issuers Actually Enforce

The total value of every 3RI request submitted for an order can't exceed the amount from the original authentication plus whatever has already been authorized against it. Issuers are expected to track this across both the authentication and authorization sides, since a merchant might authorize part of an order upfront and only need a refreshed cryptogram for what's left.

That's a one-directional cap, not a running balance that has to land on exactly zero. An order that ends up shipping for less than originally authenticated, a partial cancellation, a substitution, simply uses less of the original authenticated amount than it could have.

What This Means If You're Shipping Beyond the Window

Nothing about needing to ship past the original protection window was ever a mistake on the merchant's part. Lead times on custom goods, backorders, and advance bookings were never going to fit neatly inside a fixed window, and until 3RI existed there wasn't a way to close that gap without pulling the cardholder back in.

The practical work is a 3DS Server change: store the prior authentication details from the original session, watch the window on any order with a lead time long enough to matter, and submit a 3RI refresh request late in that window rather than early. For orders delayed long enough to need it, that refresh can be repeated more than once against the same original session.

A closely related scenario is worth its own treatment rather than a paragraph here: split shipments, where a single order is fulfilled across several separate authorizations instead of one delayed one. That's coming in an upcoming piece.

FAQ

Why does an authentication's liability protection expire at all?

Visa's guidance treats an original authentication as covering liability for a bounded window, 90 days, rather than indefinitely. Past that window, the original cryptogram no longer carries protection for a new authorization, though issuers can still treat it as evidence that authentication happened in the first place.

Does the cardholder need to be involved when a merchant refreshes a cryptogram?

No. The 3RI request goes from the merchant to the issuer directly, referencing the original authenticated session. The cardholder isn't prompted again.

Should a merchant request the refresh as soon as the window opens?

No. Visa's guidance is to wait until later in the original window rather than requesting a refresh immediately, particularly relevant for orders where the delay could stretch even further.

Can a merchant refresh the same order's cryptogram more than once?

Yes. Orders with long or uncertain lead times, travel booked years in advance being the standard example, may need more than one refresh over the life of the order.

What indicator value is used for a delayed shipment 3RI request?

Value 06 under EMV 3DS 2.2, or 15 under the Bridging Message Extension.