Trace the provider payment and store records before creating a replacement order. Check the account, mode, amount, time, status filters and trash. Then inspect any expected gateway update or fulfillment step. The absence of an order in one view does not prove no order was created, and a failed webhook does not by itself explain the missing record.
For: An owner or administrator of a research-only store who found a real provider payment with no matching store order.
Current WooCommerce documentation says a fresh block checkout creates its draft at Place Order, while eligible existing pending or failed orders can be reused during a retry. That describes the documented current flow; it does not establish what an older or customized store did.
Confirm the store and provider account, then the connection mode. Clear relevant date and status filters and inspect the order trash. Search by the provider reference where the integration records it, supported by time and amount; those details alone may match more than one order.
Write down where you searched and which records matched. An unsuccessful search is an unresolved finding, not evidence of how often orders disappear or permission to collect the payment again.
Read the provider's record of the payment itself
The provider's dashboard is the record of what the payment is: its identifier, amount, status, and which account and mode it belongs to. Copy the payment reference exactly as printed. That reference is the anchor for every other search — the store's order metadata, the gateway's notes, and any support conversation.
If the payment is a Stripe PaymentIntent, its status word tells you what stage the flow reached; a status that never reached succeeded is a different situation from a completed payment with a missing order. Check also that you are reading the payment in the same mode the store's checkout uses, since live and test data are held separately.
Separate record-searching from the integration's fulfillment step
Two different questions get tangled here. The first is a record question: does a store order for this payment exist anywhere? That is answered by searching, and it is platform-independent.
The second question is what the integration should do after checkout: create, update or fulfill a record. For Stripe hosted Checkout, session-completion events can trigger fulfillment logic, but completing the session is not always confirmation of payment for delayed methods. Inspect the actual payment status and the integration’s asynchronous-payment handling. This hosted flow does not describe how WooCommerce creates its orders.
WooCommerce’s troubleshooting guidance calls for reconciling a successful gateway charge with an order that did not update. Compare order notes with the relevant gateway event deliveries. Missing or failed communication is useful evidence, but the maintainer still needs to establish its effect before a correction.
Who repairs, and what to bring them
Once the trace has an ending, the repair belongs to whoever owns the broken link. A store order found in the wrong place is a store correction. A payment in the wrong account or mode is a provider and connection question. An integration delivery that failed is a question for whoever maintains that integration, using its own current documentation.
A useful note to any of those parties states the payment reference, the account and mode it was found in, the searches you ran and what they returned, and what you have not done — no recreated order, no refund, no second charge. It omits card numbers, account logins, and full customer records.
A consultation can help frame the storefront and provider questions. Describe the platform and which stage remains unresolved; keep full order files and credentials in the systems that own them. Confirm responsibility for any integration repair separately.
Missing-order trace
Trace the existing payment and any matching order, then record whether the expected store update or fulfillment step occurred. Finding an order does not finish the status reconciliation.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Missing-order trace. The last column is for temporary notes.
Step
Which system owns it
What to read
Your finding
Payment object and status
Which system owns itThe payment provider's dashboard
What to readThe payment reference, amount, status word, and the account and mode it was found in. Copy the reference exactly.
Store, account, and mode check
Which system owns itThe store admin and the provider account selection
What to readConfirm the correct store, authorized provider account and connection mode.
Unfiltered order search
Which system owns itThe store's order list
What to readCompare payment references, time and amount with the order list, including relevant status filters. Avoid treating time and amount alone as a unique match.
Trash and order history
Which system owns itThe store order list and available records
What to readInspect the trash and available history before concluding the order is absent.
Gateway communication
Which system owns itThe provider's event or webhook delivery log and the store's order notes
What to readRecord delivery status words (for example delivered, pending, failed). Missing notes can mean the gateway's message never arrived; a failed delivery is a fact, not proof of causation.
Integration fulfillment step
Which system owns itThe specific integration's own documentation
What to readRead the integration’s expected action and payment-status checks. A completed Checkout Session alone does not confirm an asynchronous payment succeeded.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
Do not recreate the order, issue a refund, or attempt a new charge until the existing records have been traced.
A missing or failed webhook delivery is a recorded fact, not proof of what the store did; keep record-searching separate from the integration's own fulfillment behavior.
Gateway messages and store order creation differ across integrations and versions. Use the documentation for the installed flow and its actual records.
WooCommerce: Order statuses — checked 2026-09-29. Current fresh block checkout creates a draft at Place Order and may reuse an eligible pending or failed order during a retry. Draft, pending, processing and other statuses describe different stages.
WooCommerce: Troubleshooting orders — checked 2026-09-21. Identify the gateway on the order or in the notes. A successful gateway charge with a pending order is a webhook or callback question to reconcile before fulfillment, and missing order notes can mean the gateway did not communicate.
Stripe: Receive events in your webhook endpoint — checked 2026-09-29. Event deliveries are listed as Delivered, Pending, or Failed; live-mode deliveries are retried for up to three days; event order is not guaranteed; endpoints may receive the same event more than once.
Stripe: How Checkout works — checked 2026-09-29. Hosted Checkout uses Checkout Sessions and event-driven fulfillment; delayed payment methods require asynchronous success or failure handling.
Stripe: The Checkout Session object — checked 2026-09-29. The inspected API reference (2026-08-26.preview) distinguishes session status from payment_status; complete does not necessarily mean paid.