Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Payments Callbacks

WooCommerce Payment Succeeds but the Order Remains Pending

Trace a successful WooCommerce payment that leaves the order Pending by checking gateway references, webhooks, callbacks and scheduled actions.

When the payment provider confirms a charge but WooCommerce leaves the order as Pending payment, the checkout request usually created the order successfully but the payment confirmation did not update it. The missing handoff may be a webhook, browser return, scheduled action or gateway API response.

Do not ask the customer to pay again. First match the existing charge to the WooCommerce order and protect fulfilment from both omission and duplication.

Confirm the payment belongs to the order

Compare amount, currency, timestamp, customer reference and the gateway’s merchant reference. Use the provider’s transaction ID and WooCommerce order number, but do not copy card details into tickets or notes.

Check whether the provider shows the payment as captured, authorised, pending or reversed. A successful-looking customer screen does not necessarily mean funds were captured.

Add a private order note recording the verified provider status and reference. Avoid changing the order status manually until you understand which automated event failed.

Read the order notes and gateway log

WooCommerce order notes often show when checkout began, which payment method was selected and whether a callback was received. Match those entries with WooCommerce > Status > Logs for the exact time.

Correlate:
- WooCommerce order ID
- provider transaction ID
- payment intent or merchant reference
- callback/webhook event ID
- timestamps with timezone

Redact secrets, signatures, tokens and personal data before sharing logs.

Check the webhook delivery

In the gateway dashboard, find the event that confirms payment and inspect its delivery status. A 404 suggests the endpoint or domain is wrong. A 403 often points to a firewall. A 500 indicates application failure. A timeout may mean the server processed the event but did not answer promptly.

Do not repeatedly resend the event until you confirm the handler is idempotent. A correctly designed gateway integration should recognise an already-processed event, but custom code may not.

Verify the callback URL after site changes

Domain migrations, HTTPS changes, maintenance redirects and language plugins can alter the URL used by the provider. Confirm the endpoint shown in WooCommerce matches the provider configuration and resolves publicly over valid SSL.

Exclude webhook endpoints from page cache, login protection and broad bot challenges. Create a narrow firewall allowance based on the gateway’s official requirements rather than disabling protection for the whole site.

Inspect PHP and scheduled actions

Match failed webhook timestamps with PHP error logs. A fatal error in the gateway plugin or a WooCommerce order hook can stop processing after the provider receives payment.

Some integrations queue follow-up work through WooCommerce Scheduled Actions. Check for failed or overdue jobs related to the order. Repair the underlying database, cron or PHP problem before rerunning one controlled action.

Do not delete failed actions as cleanup; they are evidence and may represent unprocessed payments.

Check status customisation

Custom order-status code, fulfilment integrations or ERP synchronisation can move a paid order back to Pending. Search private order notes for the actor and timestamp, then inspect hooks that run on payment completion.

Use WooCommerce’s payment completion APIs rather than setting database status fields directly:

$order = wc_get_order( $order_id );
if ( $order && ! $order->is_paid() ) {
    $order->payment_complete( $transaction_id );
}

This is illustrative, not a command to run blindly. Verify the transaction first and ensure the gateway’s own recovery tool is not more appropriate.

Reconcile and repair safely

For each affected order, classify it as paid, authorised, failed or uncertain. Use provider evidence and the gateway plugin’s documented reconciliation process. Only then update WooCommerce or replay a verified event.

Fix the failed boundary: correct the endpoint, SSL, firewall, plugin error, cron processing or status hook. Preserve an audit trail in private notes.

Verify the next transaction

Run one controlled gateway test and confirm the order moves from Pending to the correct paid status without manual action. Check stock, emails, provider amount, transaction ID and fulfilment trigger.

Recurring care should alert on old Pending orders with successful provider transactions, failed webhook deliveries and scheduled-action backlogs. Payment reconciliation is both an urgent repair task and an ongoing control.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident