Guest Checkout Stores Have a Post-Purchase Problem

Turning on guest checkout is one of the few uncontroversial conversion improvements in ecommerce. Forced registration is friction at the worst possible moment, and removing it reliably helps.

It also, in the same move, removes every post-purchase self-service route your store has. That trade is almost never discussed when the setting is switched on.

The accidental consequence

My Account is an account feature. A guest has no account, so:

• They cannot open an orders list, because it is behind a login.
• They cannot see their order’s status after the confirmation page has gone.
• They cannot use core’s reorder — WC_Cart_Session requires is_user_logged_in() before it does anything.
• They cannot see any action a plugin adds to My Account, because they cannot reach My Account.

What they have is the order confirmation email and your address. So every question they have — status, cancel, return, invoice — arrives as email. Not because they prefer email, but because you have left them no alternative.

There is a smaller version of the same problem for account holders who never realise they have an account: they checked out, WooCommerce created a user, and they have never logged in. Functionally they are guests too.

Measure it before you fix it

Two numbers tell you how big this is for you.

What share of your orders are guest orders? An order with a customer ID of zero is a guest order. Analytics will not split this out for you, but it is a single query, or a WP-CLI one-liner across recent orders.

What share of your support email is from guests? Take a week of customer email, look up each order, and note whether it belongs to an account.

The interesting result is the ratio between the two. If guests are 40% of orders and 65% of support email, the gap is the cost of having no self-service route — and that gap is the thing you can actually close. Doing this alongside the four-bucket inbox audit takes very little extra time and makes both more useful.

“Just make them register” is the wrong fix

It is the first suggestion every time, and it trades a conversion loss at the most valuable moment for a support saving after the sale. That is the wrong way round: the checkout is where you make money and the support queue is where you spend a bit of time.

The softer variants are better but still weak. “Create an account?” checked by default at checkout produces accounts nobody knows they have and passwords nobody has set — customers who then cannot log in, and email you about that instead. A post-purchase “set a password to track your order” email converts a small fraction and adds a message to the sequence.

The better framing: the customer does not want an account. They want to see their order. Give them that directly.

The two routes that work

Signed links in the emails you already send

The primary route, and the one that requires nothing of the customer. Every transactional email carries a link that opens their order. No password, no account, no order number to remember.

The link carries a signed token bound to the order. It expires. It grants access to that one order and creates no session — the construction, and the reason it must never log anyone in is the part to get right before shipping this.

Order number plus email lookup

The fallback, for the customer who deleted the email. WooCommerce already ships one as [woocommerce_order_tracking], and it is worth putting on a page today regardless of what else you do.

The security work that comes with it

Any guest route is a public endpoint that returns customer data, and WooCommerce order IDs are sequential. That combination is the whole problem in one sentence.

The minimum, and none of it is optional:

• Order number and matching billing email, always.
• Identical responses for every kind of failure, so the form cannot be used to test which order numbers exist.
• Rate limits per IP, per email and per site.
• Links emailed only to the address already on the order — never to the address typed into the form, or you have built a mail-bomb tool.
• Nocache headers on every order-bearing response, or your page cache will serve one customer’s order to the next visitor.

If that list looks like more work than the feature, that is the correct impression. It is the reason to use something that has already done it rather than writing a lookup form from scratch on a Friday afternoon.

Once they can see it, let them act

Access on its own moves the ticket rather than removing it. A guest who can now see “Processing” and still has to email you to cancel has been given a page, not an answer.

The useful version gives a guest the same actions an account holder gets: request a cancellation, get the invoice, ask for help with the order attached. The authorisation is different — a token instead of a session — but everything downstream of that should be the same page, the same rules and the same queue.

One genuine exception: reorder. Core’s reorder is account-only for a real reason, since the resulting cart and checkout assume a customer. Sending a guest into a fresh checkout is fine; wiring reorder to a token is more work than it is worth.

The trade, restated

Guest checkout is worth keeping. It is not a mistake and this is not an argument to switch it off.

It is an argument that the decision has a second half nobody makes explicitly. You removed a barrier before the sale and, without meaning to, added one after it. The second half costs an afternoon and some care about tokens and rate limits, and it is the difference between guest checkout being a clean win and a quiet trade.