Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Cart Checkout Symptoms

A WooCommerce Checkout Works for Administrators but Not Customers

Fix a WooCommerce checkout that works for administrators but fails for customers by comparing cache, roles, cookies, payment rules and live traffic.

An administrator’s successful test does not prove the public checkout works. Logged-in administrators often bypass page cache, carry established cookies, have different capabilities and may see payment or shipping rules that guests do not.

Treat the role difference as evidence. Compare the two requests under controlled conditions instead of repeatedly testing from the same admin browser.

Reproduce as a real visitor

Use a private browser where you have never logged into WordPress. Add the same product, select the same country and payment method, and record the exact failure. Test guest checkout and a normal customer account separately.

Check the WooCommerce order list and payment provider after each attempt. If the customer path creates an order or charge, do not repeat it until you know the transaction state.

Compare cache behaviour

Many cache systems exclude users with a WordPress login cookie. Administrators therefore receive fresh PHP output while guests receive an old or incorrectly shared checkout page.

Compare response headers:
Cache-Control
Age
CF-Cache-Status
X-Cache or host-specific cache status

Cart, Checkout, My account and WooCommerce AJAX endpoints should bypass public full-page cache. Purge after correcting the rule, then wait for cache to populate and test again. A one-time cache miss is not proof.

Compare cookies and sessions

An admin browser may already have valid WooCommerce session cookies, accepted consent and a canonical-domain history. Inspect guest cookies across product, cart and checkout.

Check whether a consent tool blocks functional commerce cookies for new visitors. Test the reject, accept and undecided states according to the store’s legal configuration. Do not reclassify marketing cookies as essential just to simplify testing.

Check role-dependent custom code

Search theme and custom-plugin code for capability checks, login checks and early returns around checkout, prices, shipping or payment methods. Code intended to hide an admin notice can accidentally skip customer processing.

Common clues include is_user_logged_in(), current_user_can() and customer-role conditions. Review both PHP hooks and JavaScript localised for particular users.

Do not edit a parent theme directly. Place a tested correction in an appropriate child theme or small site plugin and preserve version history.

Compare available payment and shipping rules

Gateways and shipping methods may be conditional on currency, country, postcode, cart total, product class, role or saved address. An administrator using a pre-filled account may never enter the failing branch.

Record the packages and rates returned for the customer request. Confirm tax calculation and totals before blaming the gateway. A missing shipping method can leave checkout unable to proceed even when the error styling is hidden.

Inspect public-only security controls

A web application firewall, bot rule or rate limit may challenge anonymous checkout AJAX while allowing a logged-in administrator. Match 403 or challenge responses with firewall events using timestamp, URI and a privacy-safe request identifier.

Create the narrowest exclusion possible for legitimate WooCommerce traffic. Do not disable the firewall for the whole site or allow arbitrary requests to sensitive endpoints.

Rule out admin-side test advantages

Administrators may use an offline gateway, see hidden products, bypass stock restrictions or have browser extensions disabled. Write down every difference in product, account, address, coupon, device and payment method.

Use a staging copy for invasive isolation, but keep gateway callbacks and outgoing email safely separated from production. Staging must not accidentally process live transactions.

Repair and verify anonymous checkout

Correct the proven layer: cache exclusions, cookie consent, conditional code, method configuration or firewall rule. Then test first-time guest, returning guest and customer account journeys on clean sessions.

Verify order creation, payment, status transitions, stock, emails and thank-you content. Keep the administrator test, but never make it the only acceptance test.

Recurring care should include an anonymous synthetic checkout after cache, security, consent, theme and WooCommerce changes. Public-only failures are commercially serious precisely because store staff may not see them.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident