# Reducing Checkout Redirects: Fewer Hops Between Cart, Payment, and Confirmation

Source: https://checkoutoptimizelab.com/2026-10-14-reducing-checkout-redirects/

Nobody designs a checkout with seven redirects. It accumulates them, one integration at a time. A payment provider that needs its own domain. A fraud check that bounces the shopper out and back. A tracking parameter fix that adds a hop nobody remembers approving. After a few years, the path from cart to confirmation looks like a subway map.

Each hop feels small in isolation, a few hundred milliseconds. But redirects compound. On a mobile connection each one is a new negotiation, and every hop is a moment where the session, the cart state, or the attribution can quietly fall apart. Counting the redirects is usually the most depressing and most useful audit a store can run.

## Where the redirects hide

The common hops fall into three buckets. Payment hops: the trip to a hosted payment page and back, sometimes with an extra bounce for 3D Secure. Platform hops: the handoff from the storefront to the checkout subdomain or app, which on some platforms happens twice, once going out and once coming back. And legacy hops: old URL structures, www versus non www normalization, and marketing redirects that were supposed to be temporary.

Most teams can name the payment hops because payments are visible and scary. The legacy hops are the ones nobody owns. They survive because removing a redirect feels like touching load bearing infrastructure, and because nobody can prove the hop costs anything. Proving it is exactly what the audit is for.

## Why hops hurt more on mobile

On a fast desktop connection, an extra redirect is a rounding error. On a mobile connection in the wild, each redirect is a full round trip with DNS, TLS, and server time, and mobile browsers are more likely to drop the in progress state between hops. A checkout that feels snappy on office wifi can feel broken on a commuter train, and the redirects are usually the difference.

There is also a trust cost. Every domain change is a moment where a careful shopper checks the URL bar, and every unexpected hop looks like the checkout is going somewhere strange. Fewer hops means fewer moments of doubt, and doubt is what turns a slow checkout into an abandoned one. The payment page that opens on the same domain as the store feels like the store. The one that jumps domains twice feels like a scam to a cautious buyer.

## Counting and prioritizing the hops

Run the real flow with a network recorder: add to cart, go to checkout, pay with the most common method, and reach confirmation. Write down every request that returns a redirect status, the domain it goes to, and the time it costs. Do the same for the second most common payment method and for a mobile user agent. The list is your redirect map, and it is usually longer than anyone guessed.

Prioritize by cost times ownership. A legacy marketing redirect that costs 400 milliseconds and that nobody remembers creating is pure waste and easy to remove. A payment provider hop is expensive but may be required by the integration; those are candidates for newer embedded payment options that keep the shopper on your domain. Remove the free waste first, then renegotiate the expensive necessity.

## What to do about payment provider redirects

Modern checkout extensibility and embedded payment elements exist precisely to kill the hosted payment page hop. If your provider offers an embedded flow that keeps the shopper on your domain, it is worth evaluating even when the hosted page works fine, because the embedded flow removes the riskiest redirect in the chain along with the branding discontinuity.

For 3D Secure and other required bounces, the goal is not zero hops but predictable hops. Keep the return URL stable, preserve cart and session state across the bounce, and test the full round trip on a real device rather than an emulator. Most lost orders in redirect heavy checkouts are not lost at the payment page. They are lost on the way back, when state that should have been preserved was not.

## Frequently asked questions

### How many redirects are too many in a checkout?

There is no fixed number, but most healthy checkouts have at most one or two required hops, usually payment related. If your audit finds legacy marketing redirects, domain normalization hops, or double handoffs between storefront and checkout, those are worth removing regardless of the count.

### Why do redirects matter more on mobile?

Each redirect is a full round trip of DNS, TLS, and server time, which is slow on mobile networks, and mobile browsers are more likely to drop in progress state between hops. A checkout that feels fast on desktop can feel broken on a phone because of hops that were invisible in the office.

### Can we remove payment provider redirects?

Sometimes. Embedded payment options keep the shopper on your domain and remove the hosted payment page hop. For required bounces like 3D Secure, the goal is a predictable round trip with session and cart state preserved, tested on real devices.

### How do we find all the redirects in our checkout?

Record the full flow with a network inspector: cart to checkout to payment to confirmation, on the most common payment method and a mobile user agent. Log every redirect status, its destination domain, and its time cost. The resulting map usually surprises everyone.