The checkout steps you can't see are the ones losing you orders

Your abandonment rate can’t tell you which step is broken

Somebody pulls the number, it comes back at seventy-something percent, and the meeting turns into a list of things to try. Baymard Institute puts the average at 70.22% after aggregating fifty separate studies, so the figure is real and yours is probably in the same neighbourhood. It is also the least useful number in the building. It is a total, and what you need is an address.

Read the reasons instead. When Baymard asks US online shoppers why they left, the biggest single answer is that they were browsing and not ready to buy, which no amount of design work recovers and which isn’t a defect. Set that answer aside and the rest of the distribution is pleasingly specific: extra costs too high at 40%, delivery too slow at 20%, not trusting the site with card details at 19%, being asked to create an account at 18%, a checkout too long or complicated at 17%, errors or crashes also at 17%, an unsatisfactory returns policy at 13%, no way to see the total cost up front at 12%, a declined card at 10%, and not enough payment methods at 9%. Seven percent gave no reason at all. That is one market’s survey, so it tells you where to look in your own checkout.

Now place each one. Extra costs, the total the buyer couldn’t see, and delivery speed all surface when shipping gets chosen. Declines, unsupported cards and outright errors land at the payment step or later. Length and the account demand aren’t a step at all, they are properties of the whole run. The returns policy belongs to the product page. So the bulk of that list happens between a buyer deciding to buy and a confirmation appearing.

Which makes the job narrow and faintly unglamorous: work out which step inside that stretch is shedding people. Not “improve conversion,” and not a redesign. One step, named, with a number attached. Conversion is only one of the ways a site underperforms, so rule the others out before you commit a quarter here. But when the traffic arrives and the orders don’t, the address is somewhere in that stretch.

The report that answers it needs a mapping first

GA4 already ships the report you need. It’s the Checkout journey report, and Google describes it as showing “the number and percentage of users who began checkout on your ecommerce website or app and completed each of the subsequent steps in the checkout funnel.” Four steps, resting on four events: begin_checkout, add_shipping_info, add_payment_info and purchase. Google states the condition for seeing anything in it just as plainly: you have to implement the ecommerce events.

That reads as a warning about negligence. Set two vocabularies side by side and it stops being one.

Shopify broadcasts the checkout moments through its Web Pixels API under names of its own: checkout_started, checkout_address_info_submitted, checkout_contact_info_submitted, checkout_shipping_info_submitted, payment_info_submitted, checkout_completed. The moments line up with Google’s four. The names don’t share a single string. So the platform is emitting what the report needs, the report is listening for different words, and bridging the two is somebody’s deliberate mapping job. Where nobody has done it, the Checkout journey report has a first bar, a last bar and nothing between them.

A team holding only a top and a bottom works on the top, because the top is the part it can see. The step losing the money never appears on a chart, so it never competes with the cart page, which does.

So the first fix is a mapping, not a redesign. Send begin_checkout, add_shipping_info, add_payment_info and purchase from whichever platform events correspond to them. While you are in there, set payment_type on add_payment_info. Google lists that parameter as optional, and it carries the most useful string in the event: the method the buyer chose. Without it you know how many people reached payment; with it you know which payment path loses them. And that blank middle costs more the more separate screens a checkout routes a buyer through, which is the next thing to count.

Count the hand-offs, because a Gulf checkout has two or three

Walk your own checkout and count the times the buyer leaves your page.

Picture the shortest possible version: a card number typed into a form on your own domain, plus a 3-D Secure challenge if a risk engine asks for one. That is zero hand-offs, or one. Add up what a Gulf checkout actually contains and you land on two or three, and not because anyone built it badly.

Saudi traffic is the clearest case. mada is the national scheme there, and SAMA’s own description of it is that it “enables the use of cards in online payment transactions at e-commerce outlets through the 3D Secure protocol.” The authentication layer is in the path by design, which is a different thing from a risk engine occasionally reaching for it. Whether a given buyer gets a challenge or passes through without one is the issuer’s call, so the step is permanently in your flow and intermittently in your customer’s way.

Buy-now-pay-later is a hosted journey, not a form field. Tabby, which states it is regulated by the UAE Central Bank, takes the buyer into its own flow to split an order into four interest-free payments or up to twelve monthly ones, then hands them back to you. A wallet sheet is another context switch, gentler and shorter. And the UAE now runs a domestic scheme of its own: Al Etihad Payments, a Central Bank subsidiary, operates Jaywan as “the UAE’s national card payment scheme,” usable online.

Meanwhile the one path that reaches confirmation with no redirect and no authentication screen is receding. Checkout.com’s 2024 MENA report records regional preference for cash on delivery halving from 41% in 2020 to 20% in 2023. Every alternative to COD hands your customer to somebody else’s screen for a few seconds, so as it shrinks, a larger share of buyers travels those routes.

So the stretch you are trying to diagnose has been getting longer here, one hand-off at a time. Write the hops down: every screen that isn’t yours, in order, for each payment method you accept. That list is what you test. It is also, near enough, the set of domains that belong in GA4’s unwanted referrals list, without which a completed order gets credited to your payment provider instead of whatever earned the visit, alongside six other defaults worth fixing in the same sitting.

The one-time code, and what actually loses it

The authentication hop has the most physical distance in it, because the code arrives in a different app. Your buyer leaves the checkout, opens Messages, reads six digits and comes back. Every part of that is an opportunity for your page to be gone when they return.

Start with the field itself, which is duller than it sounds and does a surprising amount of the work. One input, not six boxes. MDN defines autocomplete="one-time-code" as “a one-time password (OTP) for verifying user identity that is used as an additional factor in a sign-in flow”, most commonly “a code received via some out-of-channel mechanism, such as SMS, email, or authenticator application”. That attribute is the hook Safari uses on iOS to offer the code straight above the keyboard, so the buyer never switches apps at all. Chrome, Opera and Vivaldi on Android reach the same code through the WebOTP API, which takes a few lines of JavaScript. Then the input type, where MDN is blunt: type="number" “is not appropriate for values that happen to only consist of numbers but aren’t strictly speaking a number, such as postal codes in many countries or credit card numbers.” It recommends <input type="text" inputmode="numeric" pattern="\d*" /> instead. Use that for the verification code and for the card number.

What your page does while the buyer is away doesn’t look like markup work at all, and backgrounding a tab on a phone is not a gentle event. If checkout state lives only in memory, or a timer expires after sixty seconds, or a returning tab reloads and empties the form, you have built a flow that punishes the exact behaviour your payment provider requires. Persist the state, give the timer a generous window, and never clear entered fields on a return.

A wallet can remove this screen instead of smoothing it. Stripe describes Apple Pay and Google Pay as carrying “a built-in layer of authentication (biometric or password)” that supports a frictionless flow. That guidance is written for the European rules instead of these markets, and whether a particular issuer accepts on-device authentication in place of a challenge is a scheme and issuer question. Treat a wallet as a good bet on shortening the path, not a guarantee.

A decline and a missing method look identical from where you sit

The payment step is the last hop on the list you just wrote, and two entries from that US survey collide on it: a declined card at 10%, and not enough payment methods at 9%. In your analytics they leave the same trace, which is a buyer who reached payment and never came back. Same shape, different fixes, and the second one is a Gulf-specific problem.

The missing-method version is a routing question. mada in Saudi Arabia and Jaywan in the UAE are national schemes carried on cards issued by local banks, and neither is sealed off from the international networks: Checkout.com’s documentation says mada cards “are accepted both locally and globally, due to partnerships with major card schemes like Visa and Mastercard”, and Al Etihad Payments holds co-badging agreements with Visa and Mastercard that carry a Jaywan card’s cross-border transactions. So a gateway routing the international schemes alone will often authorise a card that carries one of their marks. What it can’t do is take that card on the domestic rail, which is where the rules sit: processing a mada card as mada needs a merchant ID from a Saudi acquirer, and SAMA has required payment transactions for electronic stores within the kingdom to run through mada since 2018. Accepting the domestic scheme is a configuration question at your gateway and not a logo question in your footer.

The decline version costs more than an order. In the same 2024 survey, a third of shoppers said they would switch to a competitor’s site after a single failed payment, and 23% reported a falsely declined payment in the three months before they were asked. One bad authorisation hands the customer to whoever loads next.

Your analytics can tell you which payment method loses people, once payment_type is set. It cannot tell you why an authorisation failed, and no amount of instrumentation will change that, because the reason never reaches the browser. It reaches your payment provider, so go and ask them: the decline-reason breakdown over the last ninety days, split by issuer decline, authentication failure, insufficient funds and scheme not supported. Then reconcile three counts for the same window, being purchases in GA4, settled orders at the provider, and orders in your store admin. Where they disagree, the provider is the one telling the truth.

The Arabic checkout breaks where nobody is testing

An Arabic-preference buyer travels every step on that list. And if your business runs internally in English while some of your buyers transact in Arabic, the review language and the buying language have come apart, so closing that gap is something somebody has to decide to do. Until they do, the Arabic side gets reviewed on its happy path. The Arabic version loads, the labels are Arabic and sit on the right side of their fields, and it passes.

Nobody types a bad card number.

That’s where it fails. Success copy gets written. Failure copy gets emitted, by validation libraries, payment SDKs and gateway responses, and a translation brief has to reach each of those separately. So an Arabic-preference buyer hits a declined payment, receives an English string back, and leaves. In your funnel that is an abandonment at the payment step, and a team guessing at the cause files it under price.

So go and break your own Arabic checkout on purpose: an expired card, a wrong verification code, an item that sells out between cart and confirmation, a declined authorisation. Every message that comes back should be in Arabic, on the correct side of its field, and specific enough to act on. The layout and input mechanics underneath that, including which fields have to stay left-to-right whatever the page direction says, are a larger job with its own set of rules.

What to do this week

One phone, one real card, half an hour. Not a staging environment, and not a desktop browser with the device toolbar open.

Buy something from your own store at full price, on mobile data. Do it once in English and once in Arabic. Pick the payment method your buyers use most, which may not be the one you find convenient. At the authentication step, genuinely leave the browser, open your messages, take fifteen seconds and come back, then check whether the page is where you left it and whether your details are still in the fields. Run the whole thing again on a second payment method, because the path differs and so do the failures.

Write down every screen that wasn’t yours. One walk-through gives you the hand-off inventory, the referral exclusions and the test list together.

Two things need somebody else. Map the four checkout events, so the report that answers “which step” starts filling with something. And ask your payment provider for the decline reasons, because that answer exists and it is not in your analytics.

Our Site Audit runs its performance and findability passes over the pages it can reach, which will tell you whether the templates around your checkout are slow and whether both language versions are reachable, and a sluggish payment step is a speed problem before it’s a conversion problem. What no tool will do is stand in a basement car park on one bar of signal and try to buy your own product. That half hour is still the part that finds the answer.

Standing offer

The hard part is deciding what to do first

Bring us a URL, an audit report, or a proposal you're not sure about. We'll tell you which problems deserve budget this quarter, and you'll leave with an order of operations you can hand to whoever does the work, whether that's us or not.

Book twenty minutes