A charge with no visible WooCommerce order is an urgent reconciliation incident. The store must determine whether an order exists outside the normal list, whether checkout failed after creating a payment intent, or whether custom code allowed payment before durable order creation.
Do not ask the customer to order again. Preserve their report, check the gateway and prevent a second charge while the first transaction is unresolved.
Verify what “charged” means
Ask for the approximate time, amount, currency and email used, without requesting card numbers. In the provider dashboard, distinguish an authorisation or bank hold from a captured payment.
Record the provider transaction ID and merchant reference. Search WooCommerce by email, amount and date, including Trash and all statuses. Account for timezone differences.
The bank statement description alone may not identify which store transaction caused the charge.
Search for hidden or draft orders
Modern checkout flows may create Draft or Checkout draft orders before payment. WooCommerce High-Performance Order Storage can also expose defects in old code that searches only WordPress posts.
Use WooCommerce’s order query APIs instead of assuming every order is a shop_order post:
$orders = wc_get_orders( array(
'billing_email' => 'controlled-test@example.com',
'limit' => 20,
) );
Do not run examples containing real customer data in public tools or paste their output into an unsecured conversation.
Follow the provider reference
Payment metadata often contains the WooCommerce order ID, order key, cart reference or site URL. Inspect the provider’s payment object and event history.
If the reference points to an order that WooCommerce cannot load, check database errors, order storage migration state and deleted records. Do not create a replacement order with the same number by editing database IDs.
If the payment contains no store reference, document that gap; it may indicate a custom integration started payment too early.
Inspect checkout and PHP logs
Match the provider’s creation and capture times with web server, PHP, WooCommerce and gateway logs. A fatal error after the provider authorised payment may prevent the browser from receiving success or the order from saving its final data.
Look for database write failures, deadlocks, memory exhaustion and gateway exceptions. Avoid enabling public debug display during live checkout.
A browser timeout is not proof that no server work happened. Check server and gateway state before reproducing.
Review webhook behaviour
A webhook may contain enough information to update an existing order but normally should not invent a complete order from an untrusted payload. Check whether delivery failed because the endpoint returned 403, 404, 500 or timed out.
Resend only after verifying the correct site, event and idempotency behaviour. Replaying the wrong event can duplicate fulfilment or email.
Decide whether to reconstruct or refund
Confirm with the business whether the product can be fulfilled and whether required tax, shipping and customer consent information is available. A manual order may be appropriate only when its link to the verified payment is documented.
Use WooCommerce administration or supported APIs, retain the provider transaction reference and add private notes. Do not fabricate missing tax or address information.
If safe fulfilment is impossible, refund through the provider’s documented workflow and record the result. Never mark an unverified charge as refunded merely because WooCommerce shows no order.
Repair the underlying sequence
Correct database persistence, HPOS compatibility, checkout customisation, server capacity or gateway integration. Payment initiation should be tied to a durable order/reference, and repeat callbacks must not create duplicate effects.
Test in gateway sandbox with forced failures around authorisation, return and webhook processing.
Verify and monitor
Complete one controlled transaction and trace it from checkout request to order, provider payment, webhook, stock, email and fulfilment. Confirm exactly one record at each stage.
Recurring care should compare gateway payments against WooCommerce orders and alert on unmatched references. The fastest way to handle the next incident is to detect it before the customer has to prove they paid.