Igor
A WooCommerce checkout bug is usually not "WooCommerce is broken". It is a specific step (pay, choose shipping, apply a coupon), a specific gateway, a specific cart, and often a plugin that wrapped the checkout. Capture those four, plus the error the browser or the page showed, before you call the developer. Without them you will get "works on my machine" with a test product and Stripe in test mode. This sits next to finding which plugin broke the site.
Capture this, in this order
- The step. Add to cart, cart, checkout form, choose shipping, apply coupon, pay, order-received page. "Checkout is broken" is four different bugs.
- What you saw. Exact banner text, a spinner that never ends, a 500 page, a blank pay button, a duplicate order. Copy the text.
- Payment method. The id WooCommerce uses (stripe, ppcp-gateway, bacs), not "card". Test mode or live. Saved card or new card.
- The cart. Product types (simple, subscription, booking), quantities, coupons, a mixed cart. One failing SKU is a gift.
- Customer. Guest or logged in, country, shipping versus billing mismatch, VAT.
- Order number if one was created, even a failed order in WooCommerce → Orders.
- The URL of the checkout page, and whether it was staging or production.
- Browser and device. Apple Pay and some wallets only exist on certain browsers.
Step: Pay, Stripe card, live
Cart: 1 × "Yearly support" (subscription) + coupon SAVE10
Customer: guest, shipping DE, billing DE
Actual: button shows "Processing" then the form resets. No order in wp-admin.
Console: Failed to load resource POST /?wc-ajax=checkout 500
Staging, Chrome 141, desktopCheckout is a stack, not a core file
The fault is often not woo itself. It is a field added by a checkout-field plugin, a minification plugin combining scripts, a cache plugin serving a stale nonce, a currency switcher, a subscription plugin, or the gateway's own plugin behind on WooCommerce's API. Note recent updates. If you can, reproduce with a default theme and only WooCommerce plus the gateway on staging. The binary search is in the plugin-conflict post; start with checkout-related plugins, not the SEO pack.
The request that failed
Checkout posts to /?wc-ajax=checkout (or a REST route, depending on the setup). A 500 in that request is the ticket. Copy the status and the response if it is not a stack trace full of paths you should not email. How to find it is in sending console errors and network requests. Do not paste card numbers from the payload. Ever.
What a client report can already include
If the SnagRelay WordPress plugin is on the shop, a client who clicks Report on the failing checkout sends the usual evidence plus a WordPress snapshot: WordPress, PHP and MySQL versions, theme, active plugins with versions and recent updates, PHP warnings from that request, and when WooCommerce is active the version, currency, cart item count and payment method id. They do not need wp-admin. You still confirm on staging. The plugin does not read debug.log, and a shop behind HTTP auth will send the report without the snapshot. See SnagRelay for WordPress.
What not to do
- Do not "just update all plugins" on production to see if checkout returns.
- Do not test only with an admin account and a 100% coupon that skips the gateway.
- Do not send a video of the whole screen and no order id, no gateway, no step.
FAQ
Why does WooCommerce checkout fail after a plugin update?
A checkout-field, gateway, cache, minification or subscription plugin is often behind. Find which one on staging by recent updates first, then deactivate in halves.
What information does a developer need for a checkout bug?
The step, the exact message, payment method id, cart contents, guest or logged in, order number if any, URL, browser, and the status of the checkout request.
Can I test checkout without placing a real order?
Use staging and the gateway's test mode. Some bugs exist only live (3-D Secure, wallets, live webhooks). Say which you used.
Does SnagRelay take payments or manage orders?
No. It captures the report from the page. WooCommerce remains the shop.