Payment collected, WooCommerce order pending: reconcile and restore tracking

Pause retries and establish what has actually been paid

A customer says they paid, the provider shows a successful operation, but WooCommerce retains Pending payment. Before changing the order, reconcile both records. The desired result is accurate tracking of one payment with consistent stock and fulfillment. A new payment attempt must not be used to check the first.

A bank entry visible to the customer may be an authorization, a reservation of funds, rather than a capture. Capture is actual collection by the provider; the later payout to the merchant’s bank account is another stage. These states cannot be inferred from a thank-you screen or customer-supplied screenshot alone.

This guide concerns a store already using WooCommerce and a payment gateway. It requires an administrator or shop manager authorized to read orders and access to the correct provider account. Connection changes may require additional permissions. In multisite, also verify the store site, not only the network identity. On WordPress.com, start from WP Admin if the store is installed there; gateway permissions and features remain those of that store without automatic access to server settings.

WooCommerce 11.2.1, free and published by Automattic, is the examined version. Declared minimums are WordPress 7.0 and PHP 7.4, with testing through WordPress 7.1.4. Orders and payments belong to this plugin and gateway, not native WordPress alone. The guide requires no additional installation to begin. These technical minimums do not recommend using an old PHP version.

Choose between normal confirmation, a missing notification and an exceptional correction

Open the affected order and provider operation side by side. First verify amount, currency, date, merchant account and reference. The same order number may exist in another store or test copy. Customer name and amount alone are insufficient for certain reconciliation.

If the provider reports an uncaptured authorization, do not turn the order into confirmed payment to remove the pending state. Follow that payment’s documented process with the responsible person. This differs from the already captured payment addressed here. A payment method with delayed confirmation may also normally await a banking result.

If capture is confirmed for the correct purchase, examine how the gateway sends confirmation to WooCommerce. Browser return and server-to-server notification are separate exchanges. A customer may close the tab or lose connection while the provider continues processing. Reconcile the order independently of the visible journey alone.

Prioritize restoring the confirmation mechanism, then check affected orders. A manual change may exceptionally restore commercial handling of a precisely identified order; it does not fix notification transport for subsequent orders or necessarily reproduce all gateway technical operations.

Read the exact label: Pending payment differs from On hold, which may represent normal delayed confirmation. A draft order in block checkout is not proof of capture either. Retain this initial status in the record before choosing an action.

• Payment uncaptured or still processing: retain an accurate state and follow the payment method’s own procedure.
• Payment captured and reference certain: investigate confirmation received, rejected or deferred.
• Payment captured but reconciliation uncertain: keep the case under review without requesting a second charge.
• Order refunded, canceled or disputed: examine that situation before returning it to fulfillment.

Route 1: establish reconciliation in the order

Under WooCommerce, Orders, find the entry using the agreed information and open it. Record its number, total, currency, payment method and transaction ID when stored. Read Order notes in order: they may distinguish payment request, authorization, capture, rejection and status changes.

In the provider dashboard, select the correct account and live or test environment. Open the matching transaction and find its order reference or metadata. Verify the captured amount, not only the initially requested amount. Also check for any refund already issued or another order associated with the same purchase.

Under Order notes, enter a reconciliation note with verified reference, amount and currency, check time and result. In the note-type list, choose Private note, then Add. Do not choose Note to customer for internal details, and record neither full card numbers nor login secrets.

If several orders seem to match one purchase, identify which carries the transaction before changing others. A pending order and paid order may result from a second attempt. Moving both into fulfillment would risk duplicate shipping even when only one payment was collected.

The expected result is an explicit link between the correct order and operation. This read-only route has no status change to undo. If reconciliation is uncertain, retain available references and have the merchant-account administrator clarify the case. Use neither Capture nor Refund as diagnostic buttons.

Find the incoming confirmation and its processing

An incoming notification, often called a webhook, is a provider-to-store message reporting a payment event. It is not necessarily configured under WooCommerce, Settings, Advanced, Webhooks: that area concerns notifications the store sends to other systems. Creating an outgoing order webhook does not tell WooCommerce that a provider collected funds.

In Stripe, open Workbench > Webhooks, select this store’s destination, then Event deliveries. Open the corresponding event to record its ID, HTTP code and delivery attempts. Check account, mode and destination URL. With another gateway, use its equivalent event log. Password protection, an old URL or a redirect may block receipt; opening the URL in your browser does not reproduce a signed notification.

Under WooCommerce, Status, Logs, open the gateway file at the relevant time, then fatal errors if needed. Look for a rejected signature, missing order, lock or deferred processing. Logs cannot reconstruct events before logging was enabled. Keep secrets and customer data out of a public report.

A successful HTTP response does not prove commercial validation. In examined Stripe extension 11.1.1, some validation rejections may receive 204, and an event intended for another account may be ignored with 200. Other events are processed later. Therefore cross-check delivery, log and order. If the log mentions deferred processing, open WooCommerce > Status > Scheduled Actions and find the corresponding action, such as wc_stripe_deferred_webhook. Do not execute the whole queue or erase failures.

The expected result is knowing whether confirmation never reached the site, was rejected or awaits processing. If a network rule is involved, have its scope corrected for the gateway’s documented destination. Do not remove signature validation or disable the entire firewall to accept any message.

Route 2: check the existing Stripe extension’s connection

This example specifically concerns WooCommerce Stripe Payment Gateway, published by WooCommerce, verified version 11.1.1. Its listing declares WordPress 6.9, PHP 7.4 and testing through WordPress 7.1.4. The plugin is free; use of the payment service has its own conditions and fees. Do not install it to replace another gateway during this diagnosis.

With the required permissions, open WooCommerce > Settings > Payments > Stripe > Settings. Under Account details, click Configure connection. Examine Live for live mode and Test for test mode: the expected configuration status is Configured. Verify the connected account holds the transaction. This label indicates configuration exists, not successful processing of every past event.

If this extension’s notifications were deleted or misconfigured, Reconfigure webhooks recreates them in the selected mode. This replaces old destinations pointing to the site. Record configuration first and use the command only after identifying the correct store and account.

Do not delete every destination in the Stripe account: other applications may use them. The extension documents an address such as https://boutique.exemple/?wc-api=wc_stripe, to compare with the address actually generated for your installation. This example is not a destination to copy. Account for subdirectories or another host. Prefer the extension’s own reconfiguration route over an event list and secret copied from another environment.

The expected result is a correct connection for this store and mode. Reconfiguring notifications does not guarantee automatic recovery of all old payments. Affected orders still need checking. For an account or destination error, have configuration specific to this integration restored; a replaced old signing key cannot be repaired by a simple visual undo.

Retry one notification without retrying payment

After correcting receipt, a provider may allow redelivery of the same event. This differs from another collection attempt. It may nevertheless trigger order changes and automation: check current status immediately beforehand to avoid acting on an order refunded or already processed in the meantime.

Stripe currently allows Resend from event details in the dashboard for up to fifteen days after creation. If the event is no longer available or the correct destination cannot be established, have the integration administrator examine suitable recovery. Do not use Send test event to claim reconstruction of an old real payment.

Manual redelivery does not necessarily cancel automatic attempts already scheduled by the provider. Wait for the result and reread order notes before further action. Integrations should handle repeated notifications, but custom automation may still produce an unwanted effect; do not repeatedly click to accelerate the response.

The expected result is receipt and processing of the known confirmation without a new payment operation. Check status, transaction reference and any deferred actions. If delivery is accepted but state remains inconsistent, retain response and log: identical redelivery is not a universal fix for an internal error.

Rollback concerns corrected configuration if it was unsuitable. No button undoes every effect of an already processed notification. That is why order and automation checks precede this targeted retry.

1. In the correct Stripe account and mode, open Workbench > Webhooks, the exact destination, then Event deliveries.
2. Open the already reconciled event and compare its transaction again with the order’s current state. Stop if it was refunded, canceled or references differ.
3. Use Resend once for this authorized delivery, then wait for the result. Do not retry payment or recreate an event with modified content.
4. Reread the gateway log, notes and order status; also check the identified deferred action, if any.

Route 3: correct status only after certain confirmation

This route suits an order whose full collection is established and whose automatic processing cannot be restored quickly enough, with the commercial administrator’s agreement. Before changing anything, recheck that no refund, dispute or recent change altered the situation. Also check fulfillment feasibility and stock.

Under WooCommerce > Orders, open only the reconciled order. Preserve initial status, notes and reference. In order details, choose Processing for a paid order awaiting fulfillment, then Update under Order actions. Choose Completed only when actually finished. Do not use payment capture: this route concerns already confirmed collection.

Add a private note stating the correction reason, reconciliation evidence and authorizing person. Do not change amount or products to artificially match a different transaction. Any amount, currency or reference discrepancy must be resolved before declaring the whole order paid.

Changing status may trigger email, stock updates and automation. It does not necessarily equal the gateway’s complete technical payment-confirmation call. Check whether transaction ID, paid date and integration-specific processing are present; report missing fields to the administrator instead of inventing them.

The expected result is consistent commercial tracking for this precise order. Check inventory and any notifications once. If you selected the wrong status, do not oscillate among values: returning to the previous value does not recall sent email or every triggered action. Document the mistake and have affected consequences corrected before another transition.

Monitor cancellations and neighboring orders

An order left pending too long may be canceled under stock rules. A late confirmation then requires another check before redelivery or returning it to fulfillment. The examined Stripe extension has processing that may refund a late payment on a canceled order. Therefore check current provider state and deferred actions; do not disable this behavior with a snippet to force the desired outcome.

Establish the affected period from the first known error to restoration. Examine corresponding orders individually and reconcile each with the provider. One paid example does not permit bulk approval of the entire Pending payment list. Some orders are simply abandoned or genuinely unpaid.

Do not reflexively issue a refund to simplify the case: a refund is a real commercial operation. Likewise, changing an order to Canceled does not guarantee funds are returned. Verify the financial result at the provider and tracking result in WooCommerce using a common reference.

Have the person responsible for customer follow-up communicate accurate information to affected customers: payment under review, collection confirmed or another established state. Avoid an automatic request for second payment during reconciliation. Take already sent automated messages into account to avoid contradicting manual follow-up.

Confirm future orders follow the correct route

Validate the mechanism on an isolated copy with a separate database, test recipients and real commercial integrations disabled. Configure the payment account in test mode and its incoming notification to that copy. If access protection blocks the provider, have only the necessary entry point permitted while preserving signature validation and protection of other pages. Do not make a copy containing customer data entirely public.

Start with a test order for the defined scenario: creation, provider confirmation, notification receipt and expected status. Check any deferred actions. This result does not validate every payment method; examine other affected variants separately. Keep secrets, destinations and accounts specific to each mode: a test event delivered to the live site does not prove live mode works.

Repair is complete when affected orders are reconciled, the receipt or processing cause is fixed and the checking workflow finishes correctly. Keep references for exceptional cases and verified effects on stock and notifications.

If WooCommerce already correctly records the order as paid and only email is missing, move to email-confirmation diagnosis. If the page never finishes loading before creation, return to checkout-request diagnosis. These neighboring problems do not justify changing an already accurate payment status.

Read an order using the HPOS-compatible WooCommerce API

For a maintainer with WP-CLI, this read complements visual checking without changing status. It uses the orders API, adapted to active storage, instead of a direct query assuming every order remains in post tables. Confirm the path, store and internal order ID: a custom displayed number is not always that ID.

Replace 123 with the verified ID. Keep this commercial output private. The command loads WordPress and plugins: use a trusted environment without unwanted external effects during loading. It calls neither capture, refund nor payment_complete().

A present date or reference indicates what WooCommerce recorded; it does not prove provider collection. Their absence likewise does not prove nothing was paid. Reconcile the result with the exact transaction in the payment service. No rollback is required for this read; any commercial correction remains a separate, targeted, documented operation.

wp --path='/chemin/boutique' --url='https://boutique.example/' eval '
if (!function_exists("wc_get_order")) { WP_CLI::error("WooCommerce non charge"); }
$o = wc_get_order(123);
if (!$o || $o->get_type() !== "shop_order") { WP_CLI::error("Commande ordinaire introuvable"); }
$d = $o->get_date_paid();
echo wp_json_encode(array("id" => $o->get_id(), "statut" => $o->get_status(), "total" => $o->get_total(), "devise" => $o->get_currency(), "date_paiement" => $d ? $d->date("c") : null, "reference_presente" => (bool) $o->get_transaction_id()), JSON_PRETTY_PRINT) . PHP_EOL;
'