When the user presses the order registration button and the spinner does not stop, the first step should not be to press the button again or delete the order. The order or transaction may have been made in the backend but the Ajax, redirect or JavaScript response has failed. Repeating the request at this moment can create another order or payment request.
Urgent action:Record the time, email/safe customer ID and amount; check whether an order or transaction has been created in the WooCommerce management and gateway panel. Then see the order registration request in DevTools and the WooCommerce/PHP logs as the same timestamp. Set the previous status assignment before each retry and do not enter card or secret information.
First, avoid paying or ordering repeatedly.
- Prohibit the user from multiple clicks and refresh.
- Check new orders for the same amount and time.
- Match the payment gateway transaction to the reference ID.
- Register a reserved item or coupon.
- Do not cancel or re-pay your order until the situation is clear.
If the face is broken, the bank situation and callback should be the basis for reconciliation; the spinner's message alone does not prove a failure to pay.
What do we see on Network?
Open DevTools before the controlled repetition and enable Preserve log. Find the Checkout request and enter:
- URL and method without sensitive tokens
- Status code and waiting time
- JSON or HTML response error
- redirect chain
- Repeated requests
- Console and JavaScript stack messages
If the response is an HTML error, login or security challenge page instead of JSON, the frontend may not parse it and remain a spinner.
Common scenarios
| The sign. | Possible cause. | Next check. |
|---|---|---|
| HTTP 500 | Fatal PHP or exception | PHP/error log and stack trace |
| 403 or challenge. | WAF, nonce or security rule. | Rule and access log |
| Timeout/504 | API, query, worker or proxy | Timeline Layers and Process |
| 200 with HTML. | Redirect, warning or unexpected page | Response body and route |
| Ordered, not redirected. | Gateway or JavaScript after you place an order | Order note, gateway log and console |
| No requests are sent. | Validation or JS error | Console, field and event handler |
PHP and log errors
In the WooCommerce Status logs section, check the file for the payment gateway and the date of the event. PHP-FPM or hosting error log may have a more complete stack. A general debug on the production can display sensitive paths and information; limit logging and keep error display off.The debug.log WordPress guideIt provides a safer method.
JavaScript interference
File optimization, delay/defer, template and validation plugins may ruin the Checkout handler. Check the first Console error; subsequent errors may result. In staging with the same asset mode, test the optimization plugins step by step and by clearing the cache. Do not disable all options at once as the cause will not be attributable.
WAF, CDN and Cache
A challenge or cache on a dynamic endpoint can create an unexpected response. Find the rule and request ID in the log and design the exception only for the route and behavior required. Fully disabling WAF or CDN security is not a secure solution. Checkout, cart and related endpoints must be bypassed from the public page cache.
The payment gatewayway to payment and idempotency
The creation of the request, redirect, callback, and webhook are separate steps. Timeout in response does not mean that the provider has not received the request. Retry must use the payment gatewayway-supported unified key or ID; if the plugin does not have such a guarantee, automatic replication can create multiple transactions.
Session, cookie and HTTPS
A non-harmonized domain, reverse proxy, cookie policy, or mixed HTTP/HTTPS can change the session between display and registration of an order. Check the final URL, proxy header, and domain/secure cookie.homeAnd thesiteurlWithout proxy recognition, it may create a redirect loop or exit for all users.
Query, Lock and the item.
The recording of an order has multiple write. The job report or sync may create a long lock. Apply the processlist, slow log and transaction to the timestamp request. Do not terminate the process or transaction without knowing the operation; the order may remain semi-functional and in an unknown state.
Worker shortages and timeout.
If the request is waiting in the PHP queue, the timeout increase will only prolong the wait. Measure active worker, queue, CPU, RAM, and dependencies. If the request is stopped inside the external API, the worker increase can collect more requests behind the same service.
The re-production process is safe.
- Create a clone close to production and restoreable backup.
- Direct the email and webhook test environment to a secure destination.
- Use a gateway sandbox or a controlled payment method.
- Choose a product, address and fixed delivery method.
- Record the network, console, PHP and gateway logs simultaneously.
- Just change one component at a time.
- After the correction, try retry and double click.
What can we confirm after we correct the error?
- Only one order and one payment request is made.
- Total, taxes, shipments and inventory are correct.
- Redirect and callback will be completed in a reasonable time.
- The order status is consistent with the payment gateway result.
- Email, webhook and Action Scheduler are all safe.
- Console and PHP failures are not recorded.
Common Mistakes
- Repeatedly click on the order log.
- Cancel order before reconciliation payment
- Manual change of status to Paid without proof of entry.
- Disable WAF or TLS verification
- Increase all timeout.
- A real gate test without a reverse program.
- Restore the old store database
Contact the checkout office.
If the request ends up right but is long,The Checkout for the slow detection manual.If the answer is 500,I'm looking at 500 WordPress errors.It's more appropriate to find the error layer.
When do we get immediate medical help?
If the face is broken but the order is unknown, duplicate orders are created or an error occurs only under the actual traffic, further testing can cause financial losses.Support for the WooCommerce storeIt can reconcile transactions, callbacks, order notes and logs without removing evidence.
Common Questions
If the money goes out, do we pay it back?
No, first the transaction ID and order are matched with the payment gateway panel.
Why is it only one payment method?
Compare the same port with the same API, credential, callback, and JavaScript settings in a healthy way.
Does deleting the cache solve the problem?
It may temporarily delete the old asset, but the cause of PHP does not resolve the payment gateway or session and detection should continue.