The Checkout Friction Audit: 23 Questions We Ask Before Touching Code

Every Shopify merchant who has asked us to improve their checkout has, at some point in the first call, told us about the thing they think is broken. It is almost never the thing that is actually costing them money. The shipping calculator they are proud of is surfacing costs three steps too late. The Apple Pay button they spent a weekend configuring is buried under a guest email field that no one needs. The custom upsell app is suppressing the numeric keyboard on the card fields, which means every iPhone user is fighting their own thumbs to type sixteen digits.

We learned, after enough of these conversations, that our engagement worked better if we ran our own audit first and told the merchant what we found, rather than reacting to their theory. The document below is that audit, unredacted. It is the twenty-three questions we answer before we quote a price or write a single line of code. We publish it because most Shopify brands we meet would be better off completing it themselves and handing the answers to whichever agency they hire, ours or otherwise. The cost of a good checkout audit is thinking time, not agency time.

The questions group into six areas: payment methods, shipping and surprise costs, form fields and address capture, trust signals, mobile ergonomics, and the confirmation experience. We will walk them in that order, because that is roughly the order the user experiences them, and because the money tends to leak in that order too.

Payment methods and wallet stacking

The first four questions concern who can pay, how fast, and in what currency. Shopify ships with Shop Pay, and Shop Pay is, by the platform's own telemetry, responsible for a meaningful conversion lift versus guest checkout. So the first question we ask is whether Shop Pay is enabled and positioned at the top of the wallet stack. A surprising number of merchants switch off Shop Pay because they dislike the branding, or leave it enabled but push it below PayPal out of habit. On mobile in particular, the top wallet is the one that gets tapped. If that slot is not earning its place, it is costing orders.

The second question looks at express wallets more broadly. Apple Pay, Google Pay, PayPal and Amazon Pay are not equivalent, and the mistake we see most often is treating them as a single row on the checkout page and forgetting that they should also appear on the cart page and, where the store's theme supports it, on the product detail page. An express wallet that only shows up after a shopper has clicked Checkout is a wallet that has already failed half its job, which is to let a returning customer skip the form entirely.

The third question, closely related, is whether the store honours the device it is running on. Apple Pay should appear first for a Safari user on an iPhone. Google Pay should appear first for a Chrome user on an Android. This is mostly a matter of configuration, but we often find a store serving the same wallet order to every visitor because the theme hardcodes it. The fix is small and the lift is measurable.

The fourth question addresses international payment methods. If ten percent of your traffic comes from the Netherlands, iDEAL needs to be live, because Dutch shoppers overwhelmingly default to it. If you ship to Germany, Klarna Pay Later is not optional for a non-trivial segment of buyers. We ask merchants to look at their top three non-domestic traffic sources and confirm that the locally dominant payment method is enabled. It usually is not.

Shipping costs and the surprise problem

Baymard Institute's large-sample abandonment research has, for several years running, named unexpected extra costs as the single largest reason shoppers abandon a checkout, at roughly forty-eight percent. Nothing else comes close. This is why our next four questions all concern the timing and visibility of shipping.

The fifth question is the most diagnostic one in the whole audit. Where does the shipping cost first appear in the user's journey? Shopify's default is that shipping cost is calculated and displayed at the Shipping step of checkout, which is the second step after the shopper has entered their address. That is three clicks and a full address form later than Baymard's recommendation, which is to surface shipping on the product detail page, or at absolute minimum in-cart via a postcode-based estimator. The default feels fine because it works. The revenue leak is invisible because the abandoned shoppers never reach a page you are tracking as a funnel step. This is the single change that, in our engagements, most often produces a double-digit percentage lift in checkout completion, and it is the one that merchants are most resistant to because it requires either a Liquid snippet in the cart template or a third-party shipping-estimator app.

The sixth question is about the free-shipping threshold. If the store offers free shipping above a certain basket value, the shopper needs to see how far away they are from that threshold, and the signal needs to be tied to their actual cart subtotal rather than a static banner. A progress bar showing "Add £12 for free shipping" on the cart drawer converts browsers into adders at a rate that static messaging does not. The question is not whether to have the threshold, it is whether the store is telling each shopper, in real time, where they stand.

The seventh question applies to any merchant with international traffic. If a shopper in France buys from a UK store, who pays the duties, and when are they told? The two models are landed cost, where duties are calculated and collected at checkout, and delivered duty unpaid, where the courier asks the recipient for payment on the doorstep. The second model produces refund requests, chargebacks and one-star reviews. The question is not which model a merchant chooses, it is whether the checkout is honest about which one it uses, before the shopper commits.

The eighth question closes out this section. Does the store show a delivery estimate date, rather than a range of business days? "Arrives Thursday 30 April" converts better than "5-7 business days" because it connects the purchase to the shopper's calendar. Shopify's native delivery date functionality, combined with the shopper's postcode, makes this straightforward. Most merchants leave it off because the default text works.

Form fields, address capture and the field-count discipline

The ninth question forces the merchant to confront a number they have probably never calculated. How many fields does a new customer fill from cart to thank-you page? The discipline is to open the site on a clean browser, go through the full flow, and count every input the user touches, including the email field, the address lines, the optional marketing consent tick, and the card fields. Baymard's benchmark for a well-optimised US ecommerce checkout is around twelve fields. The average store they test sits closer to twenty-three. A field count above fifteen is a leading indicator that something non-essential has been left on, usually a Company name field or an expanded Address line 2.

The tenth question is whether address autocomplete is enabled. Shopify's checkout supports this by default through Google Places, and it reduces the address step from four or five inputs to one. We find it disabled, or broken, on roughly one in three stores we audit, often because a checkout customisation or a translation app interfered with the input. If autocomplete is off, the rest of the address section is a rounding error; turning it on is the single highest-return five-minute job in the audit.

The eleventh question is whether billing address defaults to the shipping address. It should. The twelfth is whether the Company field is visible for a consumer-facing store; it should not be, because every field a shopper sees costs attention. The thirteenth is whether Address line 2 is collapsed behind a disclosure toggle labelled something like "Add apartment, suite or unit". Most shoppers do not need the field, and showing it by default tells every one of them that the form is longer than it actually is.

Trust signals and the quiet version of confidence

The fourteenth through seventeenth questions address trust, and the common thread is that trust signals work better when they are quiet and specific than when they are loud and generic. The fourteenth question asks whether security badges appear near the payment section. They should, but subtly, and not as oversized Norton or McAfee logos that look like stock photography. A small padlock with a Stripe or Shopify Payments reference does more work than a crowded badge bar.

The fifteenth question is whether the returns and refund policy is linked inline, near the Complete Order button, so a hesitant shopper can click it without leaving checkout. We often see policies only linked in the footer, which on most themes is invisible during checkout because the footer is stripped.

The sixteenth question is whether a review signal appears above the fold on mobile checkout. Not a wall of reviews, which is a conversion liability because it invites reading. A single aggregate like "4.8 from 2,143 reviews" near the product summary is enough to keep the shopper moving.

The seventeenth question is about guest checkout. Is it available, and is it labelled clearly as guest checkout, rather than hidden under an unlabelled Continue button? Baymard's testing shows that a button reading "Continue as guest" outperforms a single Continue because it names the path the shopper wants to take. Forced account creation is the cause of roughly a quarter of abandonments by Baymard's numbers, and a badly labelled guest option produces the same abandonment as a forced account, because the shopper cannot see the escape route.

Mobile ergonomics, thumb-reach and the keyboard audit

The mobile section is where the audit gets physical. The eighteenth question is the one-handedness test. We hold the phone in the right hand, in a way a tired commuter would, and try to complete the full flow using only the right thumb. We log every stretch, every time the thumb has to cross the screen to reach a button in the top-left corner, every moment the grip has to shift. The research behind this comes originally from Steven Hoober's mobile usability work and has been replicated by Baymard: the screen divides into easy-reach, stretch and hard-reach zones, and on devices over six inches the top-left is genuinely unreachable one-handed for most adults. Primary actions belong in the bottom-right for right-handers, which is most shoppers, and critical fields should not be stacked above the thumb zone in ways that require the shopper to lift their other hand. Shopify's native checkout handles this reasonably, but customisations, sticky discount bars, and live-chat bubbles routinely cover the primary CTA on viewports under 390 pixels wide.

The nineteenth question is the inputmode and autocomplete attribute audit, and this is the detail that almost every SERP article on Shopify checkout misses. On mobile, the keyboard that appears when a shopper taps a field is controlled by two attributes. The inputmode attribute tells the browser which keyboard layout to show: numeric for a pure number pad, tel for a phone pad with plus and dash, decimal for prices, email for a keyboard with the at-symbol on the main layer. The autocomplete attribute tells the browser which saved value the user can autofill: given-name, family-name, street-address, postal-code, cc-number, cc-exp, cc-csc, tel. When both are correct, the shopper sees the right keyboard and gets an autofill chip above the keyboard that completes the field in one tap. When they are wrong, the shopper types sixteen digits on a QWERTY keyboard with their thumb. Shopify's default checkout gets these right. Checkout UI extensions, custom upsells, and third-party apps routinely break them, which means every store that has added post-purchase upsells or custom fields needs this audited by hand on a real iPhone and a real Android. Not in a desktop emulator.

The twentieth question is whether the sticky order summary, which collapses open on mobile, can be collapsed again so that the virtual keyboard does not overlap the active field. A shopper typing into a field that is hidden behind their own keyboard is a shopper about to abandon. The twenty-first question, related, is whether tapping into a field that then errors scrolls the error message into view above the keyboard, rather than leaving it buried beneath it. Shopify's default behaviour is acceptable here, but custom themes often break the scroll-to-error behaviour because they override the focus handler.

Confirmation and the post-purchase moment

The last two questions cover what happens after the Complete Order click. The twenty-second question is whether the thank-you page reinforces the decision before it tries to sell anything else. A shopper who has just bought wants three things in this order: confirmation that their order was received, an expected delivery date, and a sense of what happens next. An upsell module above those three is a conversion win on the upsell metric and a retention loss on everything else, because the shopper reads the upsell as the store wanting more from them before acknowledging what they just gave. We ask merchants to lay out the thank-you page confirmation-first, upsell-second, and to measure the downstream effect on repeat purchase rather than only the immediate upsell click-through.

The twenty-third question concerns the order confirmation email. Does it arrive within sixty seconds of the purchase? Does it contain a one-click reorder link that actually works? The sixty-second threshold matters because that is roughly the window in which the shopper is still on their phone, still in a buying mindset, still likely to forward the email to a partner or open it and feel reassured. Beyond that window, the email becomes an archived receipt. The reorder link matters because it is the cheapest piece of retention infrastructure a Shopify store has, and it is most often broken on stores that have migrated themes or switched email platforms.

What to do with the answers

Twenty-three questions produces a document, not a roadmap. The way we turn it into a roadmap, when we run it for a client, is to sort the answers by two axes: expected revenue impact and effort to change. The address autocomplete question and the inputmode audit usually sit in the top-left quadrant, high impact, low effort, and become week-one work. The shipping-surprise-timing question usually sits in the top-right, high impact, high effort, and becomes a scoped project of its own. The Company field visibility and the free-shipping progress bar sit in the bottom-left, low-effort tidy-ups that the client can often ship themselves between our sprints. The trust-badge and review-signal questions sit in the bottom-right, useful but rarely the biggest lever.

If you are a Shopify merchant reading this, the most useful thing you can do is answer these twenty-three questions honestly, write the answers down, and then hand that document to whoever you hire next. If you hire us, you save us the first week of the engagement. If you hire someone else, you save yourself from paying anyone to discover facts you could have documented for free. Either way, the document is the instrument, not the agency.

If you would like us to run this audit against your store and turn it into a six-week checkout engagement, WitsCode runs structured checkout programs for Shopify brands doing six figures a month and up. Week one is this audit, run against your live store on real devices. Weeks two and three are the quick wins, shipped behind feature flags so you can measure each change. Weeks four and five are the structural work, which usually means Checkout UI extensions, express-wallet repositioning, and shipping-cost surfacing. Week six is measurement, documentation and handover. We quote fixed-fee against the audit output, not hourly against a guess. Send us the completed twenty-three answers and we will reply with a scope.