When a customer has paid but the WooCommerce order is unconfirmed, restoring new purchases and resolving affected orders are separate deliverables. The technical fault can be corrected while a list of captures, order states or refunds still needs review. That list deserves its own handover before support, warehouse and administration act independently.
This template helps you accept a WooCommerce payment repair with a bounded record of affected cases. It includes nine fictional provider records and eight fictional store orders in a downloadable example. For cause diagnosis, follow successful payment with an order still pending or a charged customer with no visible order. Here the task is deciding what must be reconciled, assigned and checked at handover.
Agree two closures: new behaviour and earlier cases
Define the corrected boundary: receiving confirmation, saving an order, processing a task or synchronising a state. The handover should connect the observed cause, applied change and a test of the affected journey. A page loading again does not establish that complete chain.
Open a separate case register for the incident period. Record its interval, timezone, provider, account and operating mode. Retain exports and their observation time. A late confirmation can legitimately change the result between two reviews.
You can accept a verified technical correction while keeping a historical case open with an owner and next decision. The reverse is possible too: staff have handled older orders manually while the underlying fault remains. Keeping both states visible prevents an interim response from looking like a completed repair.
Connect the order and payment in one record
Use verifiable provider and store references. Add currency, comparable amounts, observed state and time. A customer’s email can support a search, but cannot replace transaction identity. Two legitimate purchases can share a customer and amount.
| Section | What to retain | Decision supported |
|---|---|---|
| Identity | Order/provider references, environment and account | Find the same case |
| Amounts | Currency, gross capture and separate refunds | Classify an actual difference |
| State | Provider and WooCommerce states with time | Separate collection from commerce workflow |
| Operations | Verified stock, communications and fulfilment | Avoid a second independent action |
| Closure | Evidence, decision, owner and remaining work | Continue or accept the case with context |
The shared register does not need card numbers, credentials or a complete customer export. Keep originals appropriately and provide an extract with sufficient references. The guide to tracing payments without exposing card data helps prepare that part of the investigation.
Compare states that represent the same thing
An authorised amount and a captured amount are different states. So are a pending order, a paid order and a fulfilled order. WooCommerce’s order-status documentation distinguishes payment and fulfilment. Also review the gateway’s rules and any custom store statuses.
Compare gross capture against its commercial reference and refunds against corresponding refund records. Stripe’s documented Charge object represents captured and refunded amounts separately. Our example adopts that conceptual separation. It is neither an actual Stripe export nor a universal gateway format.
Retain currency. A value of 75 in USD and 75 in EUR does not establish a match. Currency conversion needs its own purpose and specification. The downloadable example uses integer minor units and never combines or converts different currencies.
Download the example: nine records, eight orders
We constructed fictional data with a snapshot at 12:00 UTC on 20 October 2026. A local join on the reference and first-applicable-issue classifier produced nine report rows: seven requiring review, one authorisation without capture and one aligned record within the sample.
Download the original example: three CSV files and English notes, using fictional data. It contains provider records, store orders and a review report. These are teaching worksheets, rather than production import files or an order repair tool.
| Case | What the sample contains | Classification |
|---|---|---|
| O101 | 120 EUR capture and compatible order | Records aligned in this sample |
| O102 | 80 EUR capture and pending order | Review commerce state |
| O103 | 50 EUR capture without a store-order row | Review order absent from export |
| O104 | Two 30 EUR captures for one reference | Review multiple captures |
| O105 | Authorisation, zero capture and on-hold order | Authorisation without captured collection |
| O106 | 100 EUR captured;20 EUR refund absent locally | Review refund |
| O107 | Provider in USD and order in EUR | Review currency |
| O108 | 65 EUR captured and 60 EUR order | Review gross amount |
| O109 | Pending order without provider reference in extract | Obtain provider evidence |
Every automatic action in the report is none. We accessed no store, gateway, customer or card and executed no capture, refund, event resend or stock change. O101 only matches the compared fields. It does not establish email delivery, fulfilment, bank settlement or complete incident closure.
Read exceptions before changing anything
O104 contains two captures requiring investigation. This example expects one full captured payment per order; a store using split payments would require another model. The result does not authorise refunding either record. Establish what they represent and obtain the business decision first.
O103 and O109 expose export boundaries. An order missing from a file does not establish that it never existed. A missing provider reference does not establish nonpayment. Record the next search, its owner and the source needed to resolve it.
The classifier reports the first applicable difference. A multiple-capture case might also have an incorrect state or repeated communication. Preserve those additional findings during review. The initial label is an investigation queue rather than an exhaustive account of the order.
A partial refund does not rewrite the original total
For O106, 100 EUR captured minus 20 EUR refunded leaves 80 EUR before fees. The original order total remains 100 EUR. The sample’s problem is a missing local refund record; it does not mean the original total should be rewritten as 80.
The handover should preserve both references and identify the missing record. If the provider has executed the refund, correcting local evidence must not move the money again. A real decision requires checking the provider object and following the particular integration’s supported procedure.
The guide to repairing order data while preserving payment history develops storage and supported-change considerations. This template adds the handover register so another person can review the relationship between evidence, decision and outcome.
Verify that repeated confirmation does not repeat effects
The repair needs a test appropriate to the failed event. In a prepared environment, agree how receipt, processing and outcome will be checked. Stripe’s webhook documentation covers duplicate events and the absence of guaranteed event ordering, relevant when that integration is in use.
Before any real resend, inspect the existing event and its effects. Observe order references, stock, communications and fulfilment within the agreed scope. An HTTP delivery result cannot replace checking the business task. The CSV exercise does not perform this test or establish idempotency.
The post-repair WooCommerce acceptance guide helps define new journeys and regression checks. Include the payment method, products and conditions involved in the original failure. Retain those test results separately from work on historical orders.
Decide what can close and what remains open
| Deliverable | Evidence required | When evidence is missing |
|---|---|---|
| Technical correction | Affected journey and post-change result | Verification pending |
| Historical cases | Matched references or documented decision per case | Owner and next action |
| Operational effects | Stock, notifications and fulfilment included in scope | Explicit dependency |
| Continuity | Change record and agreed recurrence control | Unassigned follow-up to resolve |
A register without unexplained differences can support closing the bounded case review. It does not turn the engagement into a complete accounting review or certify every business system. State the boundaries and identify who accepts each part.
Questions about the quote and handover
Does repair include resolving earlier orders?
The scope should say so. Ask for the interval, known case count, available sources and exception handling. An offer might restore future confirmations and price historical review separately. Compare those items and the access needed before accepting the total.
Can a case close while a business decision is pending?
Record the approved decision, supporting evidence and owner. If someone must still decide whether an operation will be fulfilled, reconstructed or refunded, retain the open case. Administrative approval and verified execution have different states. A ticket comment alone cannot establish that the decision has been carried out.
What should the next supplier receive?
The bounded register, references, applied decisions, completed tests and unresolved dependencies. Include the integration change and temporary access needing review. Continuity can then start with usable information rather than another request for the customer to prove they paid.
Keep the handover usable after the repair
Assign one coordinator to the incident register. Support may know the customer conversation, the technical team may own event processing, and operations may control fulfilment. Give each part a named reviewer so two teams do not independently act on the same unresolved record.
Record how a case reopens: a new provider event, corrected reference, discovered duplicate or later operational discrepancy. Preserve earlier observations rather than silently replacing them with the newest state. A short change history helps explain why an initially unresolved case was accepted later.
Where continuing monitoring is needed, commission its interval, sources and owner separately. This one-off incident record can inform that control, but does not establish that a daily automated reconciliation service has been installed.
A worked handover record: fictional case O102
O102 connects a pending store order with P102, a fictional 80 EUR capture. The local classification requests review of commerce state. The handover begins with those references and snapshot time. It does not yet contain a demonstrated cause or an implemented correction.
The engagement can request an explanation of why confirmation failed to reach the intended state and a proposed change. A test of future corrected behaviour needs the appropriate integration and environment. Meanwhile, the store owner reviews the historical case and coordinates its treatment to prevent independent actions.
The outcome field remains pending until new evidence exists. If an authorised local correction is applied, the record should retain P102 and explain the change, approver and checked effects. Acceptance requires evidence for each claim; the CSV label does not authorise fulfilment.
Customer support also needs the approved communication and its owner. The register can identify that task without containing the entire private conversation. Everyone can then work from the same reference, with a customer response consistent with the business decision.
When an acceptance check fails
Retain the attempt, observed outcome and next hypothesis. If confirmation works but repeats a notification or stock movement, the relevant check still fails. Keep that attempt in the record. Agree the correction and next verification before closing the scope.
When missing access or an external dependency blocks progress, name its owner and the evidence needed to continue. That gives the next stage a concrete problem to estimate while preserving the investigation already completed.
Prepare an assessment around one concrete case
Collect the store URL, affected method, interval, symptom and references with private information removed. The checkout diagnostic brief for 2027 helps organise the first request. For WooCommerce checkout repair, agree both the new-journey test and the historical-case handover.
The ecommerce recovery process explains assessment and approval. Request an assessment with the available register. A useful handover lets technical staff, the store and customer support see what is resolved and who continues the remaining work.
A payment notification fails: an observed WooCommerce laboratory case
The reconciliation exercise above uses synthetic lists. We also ran a separate, executable case on 25 October 2026: one native WooCommerce checkout, a real WooCommerce order and stock record, and a custom gateway connected by HTTP to a local payment simulator. The simulator recorded a fictional €39.00 charge; no bank, card network, real processor or money was involved.
The isolated installation ran WordPress 7.1.3, WooCommerce 11.2.1, PHP 8.3.36 and MariaDB 11.4.12. Chromium 152 submitted the checkout. The following retries and notifications were HTTP calls from the test harness. These are seven observed steps, not seven customer purchases or a test of a commercial gateway.
| Observed step | Order state | Simulated charges, total | Stock |
|---|---|---|---|
| Native checkout | pending |
1 | 10 |
| Gateway request repeated | pending |
1 | 10 |
| Invalid signature: HTTP 401 | pending |
1 | 10 |
| Callback unavailable: HTTP 503 | pending |
1 | 10 |
| Same callback recovered: HTTP 200 | processing |
1 | 9 |
| Paid event repeated: HTTP 200 | processing |
1 | 9 |
| Late failure event: HTTP 200 | processing |
1 | 9 |
What the trace actually demonstrates
The first checkout created one pending order. The simulator stored one charge under an idempotency key tied to that order. Repeating the gateway request returned the existing charge. We then sent an incorrectly signed notification, which was rejected with HTTP 401, followed by a correctly signed notification with a deliberately induced HTTP 503. The order remained pending and stock stayed at 10.
Retrying that same signed event succeeded. The handler called WooCommerce’s payment_complete() with the simulated transaction reference: the order moved to processing and stock fell to 9. A repeated paid event did not reduce it again. A later failure event did not overwrite the paid state. The final record contained one order, one simulated charge and the matching transaction reference.
Download the observed trace, seven-row CSV and scope notes. The ZIP contains fictional references and measured results, without credentials or executable gateway code. Callback recovery took 272.975 ms in this local run; that is a harness measurement, not a provider latency promise.
Where this evidence stops
The gateway’s signature checks, event handling and idempotency were written for this laboratory. They do not prove that an installed Stripe, PayPal or other gateway behaves identically. Classic checkout was exercised; Checkout Blocks, 3-D Secure, real refunds, simultaneous workers, external delivery retries and customer email receipt were not tested. Production repair still needs a matching test in the actual provider’s sandbox and the store’s own integrations.
We used WooCommerce’s documented payment gateway API. Its test-order guidance also explains why test orders and integrations need care. Here the whole installation was private, external mail was suppressed, and its containers, network and generated credentials were removed after recording the evidence.