Classify the failure before creating another order
A spinning checkout, a field-validation message and a bank decline require different investigations. Record the exact stage, time and time zone, affected payment method and recent changes without collecting card details.
- Loading or validation: note whether checkout renders, shipping or totals update, and the submit action produces an error. Check whether the failure affects all methods or only one, and whether an order was created.
- Declined payment: inspect that order's notes and the provider's decline information. Follow the gateway's documentation or contact its support; do not assume a theme change will resolve a processor or issuer decision.
- Pending, on-hold or timed out: reconcile the order with the provider's record, including any authorization or capture. A delayed payment notification can leave the storefront and provider showing different states.
Correlate order notes, logs and provider status
Use one affected order and a narrow time window to connect the customer-facing symptom with server and gateway evidence. Check the provider's service-status page for an incident at that time.
- Review WooCommerce order notes and WooCommerce → Status → Logs. If the gateway supports diagnostic logging, enable it only as needed using that gateway's documentation, then disable temporary logging after diagnosis.
- Check the provider dashboard for the corresponding transaction and notification attempts. Confirm configuration and credential environment privately; investigate blocked or failed callbacks with the host and gateway support rather than disabling security controls broadly.
- Review the WooCommerce System Status Report for component versions, configured checkout pages and relevant environment warnings. For a spinner, have a developer inspect failed browser requests and server errors, plus cache or script-optimization changes.
Reproduce safely on isolated staging
Before conflict testing, preserve the live store's files and database. Create a protected staging copy that cannot charge real customers, send customer emails or trigger live fulfilment and subscription actions.
- Configure sandbox credentials and test payment methods only on isolated staging, following the gateway's documentation. Never flip a live store into test mode to diagnose a customer's failed purchase.
- Reproduce the affected checkout journey with synthetic customer data. On staging only, compare a supported default theme and a minimal plugin set retaining WooCommerce and the gateway, then reintroduce components one at a time.
- After identifying a supported fix, plan a narrow production change and rollback. Do not overwrite new orders with an old staging database. Verify checkout validation, provider confirmation, order status, stock and notifications through an agreed payment-verification procedure.
Relevant official documentation
Gateway behavior varies. Use the documentation for your installed gateway as well; these references do not establish a particular transaction's payment state.
Need someone to investigate?
See WooCommerce checkout repair, or describe the failing stage, gateway name and recent changes. Do not send customer payment data or secret keys through the form.
Request checkout help ↗