VIENNA / WEBSITE REPAIR & SUPPORT / REMOTE SERVICEsupport@virtuaworx.net ↗

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.

  1. 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.
  2. 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.
  3. 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.
Do not retry charged payments blindly, manually mark orders paid, or issue speculative refunds. Resolve an uncertain transaction with the provider first, and tell the customer not to submit repeated payments while it is investigated.

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.

  1. 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.
  2. 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.
  3. 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.
Never request or paste full card numbers, security codes, API secrets, customer records or unredacted logs. Reports and browser captures may contain personal data or tokens; redact them and use an agreed private support channel.

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.

  1. 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.
  2. 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.
  3. 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.
A successful sandbox transaction is not proof that live credentials, callbacks and settlement work. Confirm the live configuration with the provider; any live verification must be separately authorized and controlled.

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 ↗