Check which checkout option is selected before the customer notices
Somewhere on your checkout or payout screen, one option is already selected. If that default costs the customer more—or you more—the quiet choice is doing work you never wrote down.
Open your own checkout and payout flows as a customer would. Note which shipping, tip, payment method, transfer speed, or add-on is pre-selected, what it costs, and whether a cheaper or clearer option requires an extra click. Change defaults on purpose, label fees in plain language, and record who owns the screen so a newly installed app cannot silently flip the choice.
Start on the screen the customer sees
Open an incognito window. Add a real product to the cart. Walk to the last step before pay. Do not use the admin preview if it softens anything. You are looking for one boring fact: which choice is already on when nobody has touched it.
Shipping speed. Tip percentage. Express checkout versus card. "Save my card." Newsletter opt-in. SMS updates. Instant payout versus standard. Gift wrap. Warranty. Each of those can arrive pre-checked or pre-highlighted. A pre-selected option is a pricing decision wearing a UX costume.
Write down four columns for every default you find: what is selected, what it costs the customer (or you), what the alternatives are, and how many clicks it takes to change. If you cannot answer the cost column in one sentence, the label on the screen is not doing its job.
How the work moves
Incognito walk for checkout defaults
- Cart as a stranger
Incognito session, real product, no admin soft edges.
- List pre-selected options
Shipping, tips, payment, add-ons, marketing opt-ins.
- Price each default
Customer cost and your cost in one sentence each.
- Count the clicks
How hard is the cheaper or clearer alternative?
- Assign an owner
Who may change the default after an app install.
Walk the money paths separately
Checkout and payout are different screens with the same failure mode. On checkout, a costly default taxes the buyer. On payout or withdrawal, a costly default taxes the seller or the account holder—sometimes you.
For checkout, complete a test order with the default left alone, then a second test where you deliberately pick the cheapest honest option. Compare totals, emails, and the order record. For payout, if your platform pays you or your sellers, open the withdrawal flow the same way. Note whether "instant" or "standard" is highlighted, and whether the fee appears before confirm or only after.
If a marketplace or wallet sits between you and the customer, repeat the walk in that skin too. Defaults often differ by channel even when the catalog is the same.
A pre-selected option is a pricing decision wearing a UX costume.
Name who can change the default
Platforms, themes, and apps all touch checkout. After the HulkApps-style lessons in our note on apps that can edit your checkout, treat default-changing permissions as sensitive as discount or payment permissions. Keep a short list: which apps may alter shipping rates, payment methods, tips, upsells, or transfer speed. Remove access that is not required this quarter.
When you install something new, re-run the incognito walk the same day. Do not wait for a customer screenshot. Put the re-check on the install checklist next to "test discount code" and "test refund."
Decision guide
Default left alone vs default chosen
| Consideration | Inherited default | Chosen default |
|---|---|---|
| Origin | Theme, app, or platform leftover. | Written decision with a named owner. |
| Label | Vague name, fee after confirm. | Cost and timing visible before pay. |
| After install | Nobody re-checks the screen. | Incognito walk on the install checklist. |
| Customer view | Surprise on the bank statement. | Tradeoff understood at checkout. |
| Audit | No record of who flipped it. | Change logged with ticket or changelog. |
Rewrite the label, then decide the default
Sometimes the fix is not flipping the default—it is saying what the default costs. "Arrives Thursday · $12" beats "Express" alone. "Standard · usually 3 business days · no fee" beats a vague secondary radio button. If you keep a higher-cost default because it is operationally necessary (cut-off times, carrier contracts), say so in one plain line. Customers forgive a clear tradeoff more readily than a quiet upcharge.
Decide in writing:
- Which default is intentional, and why.
- Which default was inherited from the theme or an app and was never chosen.
- Who may change it, and where the change is logged.
Keep that page with your other commerce runbooks. The next theme upgrade will try to forget it.
Examples of defaults that quietly decide
Illustrative patterns, not accusations of any brand: a payout screen highlighting instant transfer with a fee while standard sits a click away; a tip module starting at a high percentage; shipping defaulting to the fastest method your rate table returns; an add-on warranty pre-ticked after an app install; marketing SMS opted in because a checkbox defaulted on. Each can be intentional. Most were never reviewed after the app that introduced them went live.
Bring three people to the walk: someone from support who hears complaints, someone from finance who sees margins, and someone who can change the theme or app config. Disagreement in that room is useful. It means the default was never a company decision.
Document the walk with dated screenshots stored beside your checkout changelog. Future you will not remember what the green button looked like last April.
Peak season deserves a freeze: no new checkout apps after a set date without a re-walk and a named approver—the same spirit as a config freeze before cutover.
Accessibility belongs on the walk too. If the cheaper option is visually faint, or the fee appears only after focus moves, you do not have a fair default. Fix contrast and copy while you fix the economics.
Put the walk on a calendar
Do this walk after any checkout app install, theme update, payment-provider change, or peak-season config freeze. Fifteen minutes beats a week of "why is everyone choosing the expensive one" guesswork.
We build and tune ecommerce checkouts with those ownership questions in mind. If your defaults have not been walked in months, talk to us.
Finally, separate experiments from defaults. A/B testing a higher tip suggestion is a time-boxed experiment with an owner and a stop date. A permanently pre-selected paid option without review is how experiments become silent policy. Label experiments in your changelog. When they end, either promote the winner as an explicit default or revert.
If your checkout is assembled from multiple apps, keep a diagram of which app owns which module—shipping, tips, upsells, wallets. Ownership diagrams prevent endless "I thought their app did that" conversations after a fee complaint.
If you operate in multiple countries, walk each localized checkout. Defaults and fee disclosures differ by currency, tax display, and local payment methods. A careful US walk does not prove the EU or APAC skins are honest. Add localized walks to the same calendar as theme updates.
When you find a costly default you want to keep, write the reason in one sentence next to the screenshot: carrier cutoff, contract, or margin need. Future theme updates will try to reset it. A sentence in the changelog is how the choice survives staff turnover.
Re-walk after payment method additions too—wallets and pay-later options often arrive with their own pre-selected speed or fee. The calendar entry can be short; the habit is the point.
Support macros should know the intentional defaults too. When a customer asks why express was selected, the answer should match the changelog sentence—not a shrug. Consistency between the screen and the inbox is part of the same walk.
Related work: Paddle8.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.