When a customer receives a payment successfully or the amount is deleted from their account, but the order is still unpaid, pending payment or on hold, you should not immediately create a new order or leave the situation unchecked on Processing. The problem usually occurs in the browser return, webhook, verify phase, amount matching or hook execution after payment. First, the financial reality in the payment gatewayway panel must be matched with the store record.
Urgent action:You will not be repaid from the customer. Enter the order number, amount, time, non-sensitive reference ID and transaction status in the payment gatewayway panel. Temporarily control the inventory and delivery with the internal process, but do not delete the order data. Then follow the callback and verification in the same timestamp log.
Successful from which system?
The browser receipt, bank text, gateway panel status and verify status in the API are not the same. The initial fraction may be returned later; on the other hand, payment in the panel may be final but the verification response has not been delivered to the store. The decision reference should be the official gateway documents and API and its traceable result, not just a screenshot of the customer.
See the payment chain step by step.
- WooCommerce creates orders and attempts to pay.
- The store takes the API through the token or authority.
- The client browser is moved to the payment gateway.
- The payment gatewayway sends the result to the browser callback or webhook server.
- The add-on verifies the amount and ID with the API.
- If successful, the order is marked paid.
- It's a resource, email, webhook and the next operation.
Failure at each stage is indicated differently. For example, browser shutdown should not stop final validation forever in a healthy webhook architecture; but accurate behavior depends on gateway capability and plugin implementation.
Before any change, reconcile.
| The data. | The store. | The payment gateway. |
|---|---|---|
| It's an I.D. | Order number and transaction ID. | official authority/reference |
| The amount. | Total and currency | Number and unit registered |
| The time. | Creating and last modifying order | Creation, payment and settlement |
| The situation. | Pending/Failed/On hold | Failed, succeeded, verified or refunded. |
Do not leave any sensitive ID or card details on a public ticket. If multiple orders have the same amount, only the amount and time is not enough to apply; a single ID is required.
Browser callback is not received.
The user may turn off the tab, interrupt the internet, or be redirected by the browser, a privacy plugin, or language path disrupted. Check the access log for URL callback, status, and redirect chain. 404, 403, loop, or login path are important evidence. If the webhook has an independent gateway, check its access and signature separately from the browser.
Verification has failed.
The plug-in will usually send the ID, amount, and request data to the payment gatewayway API after the callback. Timeout, DNS/TLS, incorrect credential, amount difference, or previously verified code should be interpreted according to the payment gatewayway's documentation. Do not consider the previously verified message to be automatically unsuccessful or successful; first, specify that the previous verification was for the same order and amount.
Real and Toman or Total order.
If the store receives the amount with one unit and the payment gatewayway with another unit, the transaction or verify may be inconsistent. Discounts, taxes, shipping, rounding and order changes after delivery also vary. Compare the initial sending amount, callback/verify amount and total stored without manual manipulation.
Webhook has encountered WAF or Cache.
WAF, Geo-block, rate limit, maintenance mode or compulsory authentication can reject a gateway server request with 401/403. The cache should also not replace a personal callback response. Find the specific rule ID and request and make a minimal exception; do not turn off whitelisted IPs and the entire WAF.
Fatal Error after confirmation of payment
Sometimes verify is successful but a hook related to asset reduction, email, factor, CRM or text exception. You should check whether the payment gatewayway plugin committed the payment status before the hook. Check the PHP error log and WooCommerce log at the same time. Re-implementing the hook without recognizing idempotency may impose the asset or message twice.
HPOS and port compatibility
In a store that has High-Performance Order Storage enabled, the plugin must read and write the order from the supported WooCommerce APIs. An older plugin that is directly dependent on the previous storage structure may record transaction ID or status in the wrong place. Check the declared compatibility status of the plugin, feature settings and logs; do not manually synchronize or unify tables.
For testing, create a clone with the same HPOS status and versions. Check order creation, payment, lookup with ID, refund and management report. Turning off HPOS on production without evaluating migration and current orders is not a low-risk solution.
Cron and Action Scheduler
Some plugins reconcile, webhook retry, or perform a post-payment operation in the queue. Check for failed/pending actions based on hook, age, and exception. Deleting all jobs is not the solution and can delete confirmation, email, or sync orders.
Why is a handshake a dangerous situation?
Placing an order on Processing may result in email, inventory reduction, accounting webhook, and fulfillment, while money may not be settled or the same operation may already be partially settled. First, keep a definite financial result and a history of the notes.
Do not start the automatic or manual refund in a hurry.
If the order fails but the transaction is finalized, first specify whether the goods are delivered or must be returned. A refund from the payment gatewayway panel and a refund from WooCommerce may be two different paths with separate webhooks. Execution of both can create a repeat request. Check the store policy, settlement status and idempotency API and enter the refund ID in the internal order note.
In case of a group event, keep the order list with a single identifier and follow up each case to one of the transfer, refund or need-to-follow modes; the sum of the amounts alone does not take the place of the transaction-to-transaction matching.
Safe procedure for a real order.
- Inform the customer that the payment is not repaid.
- Take snapshots or backup of orders, notes and logs.
- Find the transaction in the official gateway panel/API with a unique ID.
- Apply the amount, unit, time and settlement/verify status.
- Find callback, webhook and log verification at the same time.
- Reproduce the technical cause on staging or with non-sensitive data.
- Forcing the order by recording the note and without re-implementing the idempotent operation.
- After the correction, test successful payments, cancellations, timeout and repeat callback.
Repeat callback control.
The payment gatewayway may retry the webhook or the user refresh the return page. The handler must block the re-enactment of the transaction operation with the transaction ID and current status. Test the same callback twice, order or decrease the second item, and respond appropriately to the payment gatewayway. An overall lock or removal of an unregistered repeat request also makes it difficult to troubleshoot.
Prevention and monitoring
- Monitor the successful transaction rate on the order.
- Beware of old Pending/Failed and webhook 4xx/5xx.
- Enter the request ID and the non-sensitive transaction ID in the structured log.
- Run an end-to-end controlled payment after each update.
- Monitor system timing, DNS, TLS and callback access.
- Runbook define financial compliance and responsible access for respondents.
Common Mistakes
- Request for repayment before inquiry
- Delete the order or log to restart.
- Manual change of status without financial confirmation.
- Trusting only screenshots or text
- Running the callback with a manual URL on the production
- Register the secret and token in the log.
- Disable TLS verification or WAF
- Restore old database and lose new orders
The distinction between this error and the public corruption is
If no user enters the payment gateway, firstThe breakdown at the Walkhamers Gate.If the order is made before redirect but the interface is waiting,Catching the check-out.This is a guide when there is a successful financial witness but the order status is not consistent.
When do you need special assistance?
If you have several successful payments with a failed order or you don't know which callback has executed the existing operations and fulfillment, a direct change in the situation can exacerbate the financial problem.Support for the WooCommerce storeIt can execute orders, transactions, verify, webhook and server logs in a timeline and offer a verifiable correction path.
Common Questions
If the money is broken, is it a successful payment?
Not always; some pieces are unsuccessful and reversible.
Can I handle the order manually?
Only after financial compliance and recognition of the hook effect, should the action be recorded and in accordance with the store runbook.
Why is the order on hold?
The expected behavior may be a payment method or a verification result. note see order and gateway documents before change.
What happens if the callback is doubled?
The correct implementation should manage repetition idempotent; test it with a test transaction and an item/email check.
Does deleting the Action Scheduler help?
No, it may remove the job needed to reconcile or order the operation. First identify the failed hook.