The customer clicks the order button, the spinner runs and the gateway window appears several seconds later. That pause usually occurs before the customer reaches the payment provider. WooCommerce may still be validating fields, recalculating totals, creating an order or requesting gateway configuration.
Measure the checkout request separately from the payment window. Blaming the gateway too early can lead to switching providers while the same WordPress bottleneck remains.
Define the exact waiting interval
Use the gateway’s sandbox or authorised test mode. Start a browser performance and network recording immediately before the final checkout action.
Note which request begins the wait. Depending on the checkout integration, it may be a WooCommerce Store API call, ?wc-ajax=checkout, an AJAX update or a provider endpoint.
Record response time, status and whether the browser waits for a server response or spends time executing JavaScript afterwards. Do not capture card numbers, personal details or authentication tokens in shared evidence.
Compare checkout updates with final submission
WooCommerce can recalculate checkout when address, shipping method or payment method changes. If those updates are already slow, the final click may simply expose a broader totals problem.
Test:
- initial checkout load;
- postcode or country change;
- shipping-method selection;
- coupon application;
- final order submission.
One slow transition may identify the hook or external service involved. Disable no tax or shipping rules on production merely for testing; use staging with representative configuration.
Inspect PHP and database time
Use application tracing or a controlled WordPress profiler to inspect the slow endpoint. Look for repeated product/meta queries, cart recalculation, subscription rules, multilingual lookups and custom checkout fields.
Match the trace timestamp to PHP-FPM and MySQL evidence. A slow response can include worker queueing before WordPress starts.
Do not add an index from a generic recommendation. Capture the real query and test schema changes on a database copy.
Find external calls before payment
Shipping quotes, tax services, fraud checks, address validation and gateway token setup can make remote requests before the payment UI opens. A slow or unreachable service can hold a PHP worker until timeout.
Inspect outbound-call traces and provider logs. Define conservative timeouts and supported fallback behaviour. Do not bypass a required fraud or authentication step for speed.
Cache only stable reference data where the integration permits it. A live quote or payment token is not a normal cache candidate.
Check checkout JavaScript and optimisation
Delayed or combined JavaScript can cause repeated checkout refreshes or initialise the payment component late. Review console errors and the network waterfall for duplicate gateway scripts.
Temporarily disable only JavaScript delay in staging. If the window opens normally, exclude the smallest verified dependency chain rather than all scripts.
Consent settings must also permit essential payment code according to the approved configuration. Test accepted and rejected optional consent without reclassifying payment functionality casually.
Review custom hooks and emails
Custom code attached to order creation may perform remote CRM calls, generate PDFs or send email synchronously. That work can happen before the browser receives the result.
Move non-essential post-order processing to a reliable background action only after ensuring it is idempotent and monitored. Payment status, stock and customer confirmation must remain consistent if a background job retries.
Never edit a parent theme or gateway plugin directly.
Verify the commercial outcome
Repeat authorised test purchases with common shipping, tax, coupon and payment combinations. Confirm one order is created, stock changes once, the gateway receives one attempt and the confirmation page appears.
Measure the interval from click to payment window, not only full page load. Monitor checkout errors and completed orders after release.
Request urgent repair when customers abandon at the spinner, duplicate orders appear or the delay is intermittent. Begin with timestamps, test method and sanitised request evidence; use a secure channel for later access.