A customer says they have paid. Stripe shows a successful payment, but the WooCommerce order is still marked Pending payment. Your team cannot tell whether to pack it, send another payment link or wait.
Start by matching the payment to the order and checking its actual state. Then trace the notification back to your website. Changing the order status alone can hide the fault while the next customer encounters the same problem.
This guide covers one-off orders using the official WooCommerce Stripe extension. WooPayments and third-party Stripe plugins have their own connection settings and recovery procedures. Identify the installed gateway before following instructions.
What Pending payment does, and does not, tell you
WooCommerce’s order-status documentation distinguishes Pending payment, where the order is awaiting payment, from Processing, where payment has been received and fulfilment is outstanding. Completed means fulfilment is finished. On hold can be appropriate while payment confirmation is outstanding or funds are authorised but not captured.
If Stripe and WooCommerce disagree, treat that as a reconciliation problem. A status in one system is not enough to settle what happened in the other.
Also separate a missing email from a missing payment update. If the order is already correctly paid and appears in your fulfilment queue, investigate the notification route separately. Changing a correct order back and forth to provoke an email makes the record harder to follow.
1. Match the Stripe payment to the exact order
Choose one affected order and one successful comparison from the same checkout route. Record the order number, attempted payment time, amount, currency, gateway and current status. Read the order notes before making changes.
The official extension can include Stripe identifiers in the order details and notes. WooCommerce’s guide to Stripe order information explains where these appear and how the linked identifier opens the corresponding transaction. Use that reference wherever available rather than matching only by customer name or amount.
In the correct Stripe account and mode, check whether the matching payment succeeded, remains uncaptured, failed or was refunded. Confirm that it belongs to this website and this order. If the customer tried twice or switched payment methods, investigate each attempt separately.
Keep a short incident record:
- The WooCommerce order number and matching Stripe transaction reference.
- The payment state and the order state, checked at the same time.
- The first point where the two records stop agreeing.
- Who will resolve the order and what the customer has been told.
Ask the customer for their order reference and what they saw at checkout. A bank screenshot alone cannot establish which website record should be updated. Avoid asking them to repeat checkout while the original attempt is unresolved.
Check authorisation before calling it a paid order
A card authorisation reserves funds for later capture. Stripe’s authorisation and capture guidance explains that authorised payments can have a requires_capture state, and that an expired authorisation releases the funds. A customer’s banking app may not clearly distinguish an authorisation from a captured payment.
If your business deliberately captures funds later, check the gateway’s capture workflow. An uncaptured authorisation needs that workflow, not a manual change that merely makes the website look paid.
2. Check the Stripe extension’s webhook connection
A webhook is a notification Stripe sends to your website when something changes. It helps the store learn the payment outcome independently of what the customer sees in their browser.
The dedicated WooCommerce Stripe webhook guide says webhooks are configured automatically when connecting the extension from version 8.6.1 onwards. Older advice telling every merchant to create them manually can therefore send you down the wrong route.
For this extension, go to WooCommerce > Settings > Payments > Stripe > Settings, open Configure connection in Account details, and check the Live and Test tabs. The guide identifies the expected webhook status as Configured and describes reconfiguration where needed.
Check live mode for a real customer incident. A healthy test connection does not establish that the live route worked. Equally, a Configured label is not your final acceptance check: the affected payment must reach the correct order.
If an endpoint is missing or points at an old website address, have the developer compare it with the installed extension’s guidance. Check which integrations share the Stripe account before reconnecting or removing endpoints. Preserve delivery evidence first.
3. Find the affected event, then follow it into WooCommerce
Stripe’s webhook documentation explains how to inspect an endpoint’s Event deliveries in Workbench, including delivery state, HTTP response and retry information.
Find the payment-related event for the matched transaction and inspect its destination. Common responses help narrow the investigation:
- A redirect: Stripe treats webhook redirects as failures. Check the destination URL.
- A 4xx response: check whether the route exists and accepts the request.
- A 5xx response: inspect application errors at that time.
- A delivery marked successful: continue into the order notes and website logs.
Successful delivery establishes that the endpoint responded successfully. It does not, by itself, demonstrate that your order, stock and dispatch workflow are now correct. That is why the order record remains part of the test.
Ask your developer to follow this particular transaction through the gateway handler. Does it find the right order? Does it record payment completion? Does a custom extension change the status afterwards? Compare the sequence with the successful order you selected earlier.
WooCommerce’s order troubleshooting guidance directs merchants to order notes and WooCommerce > Status > Logs. Logging enabled afterwards captures new transactions; it cannot recreate an earlier missing log. Use a controlled test if more evidence is needed.
If the incident began after a deployment, include changes to the domain, hosting, checkout, security rules and payment extension in the investigation. Test a suspected extension conflict on staging. Give the developer references and timestamps through your normal support channel so they can investigate the same event.
4. Recover the affected order without collecting payment again
Once you have established that the correct payment succeeded, resolve that existing order. WooCommerce’s troubleshooting guide recommends checking or resending the gateway notification and reconciling the order before fulfilment.
Have the developer repair the fault before a controlled resend. Stripe can retry failed deliveries automatically, and manual resends do not cancel that retry behaviour. Recovery should therefore tolerate another delivery of the same event.
Where automatic recovery is unavailable, ask the gateway support team or developer for a supported reconciliation procedure. Record the payment reference, intervention and outcome in the order notes. Verify payment recording, stock, customer notification and the fulfilment queue together.
Do not create a replacement paid order just to get something into dispatch unless your recovery process accounts for the original record. The aim is one clear order, linked to the correct payment, with a traceable route to fulfilment.
If the order has already been cancelled
WooCommerce’s Hold stock setting can cancel eligible Pending payment orders after the configured interval and release reserved inventory. That can leave you with a successful Stripe payment and a cancelled website order when the payment update did not complete.
Check stock availability and whether a refund has already occurred before promising dispatch. Agree whether the business will fulfil or refund, then follow the gateway’s supported process. Changing an order label is not evidence that the customer’s money has been returned.
5. Test the repaired customer journey
Use a separate staging environment with the correct Stripe test connection. The official Stripe extension testing guide explains test-mode purchases and test cards for different outcomes without charging real payment methods.
Build the checks around your actual checkout:
- A successful card payment: the transaction matches one order, reaches the expected paid status and enters fulfilment.
- Bank authentication: completing the additional step produces the correct outcome; abandoning it does not falsely mark the order paid.
- A declined payment: the customer sees a useful recovery route and the order does not enter dispatch as paid.
- Any delayed-confirmation method you offer: the eventual result reaches the original order.
- A repeated notification: the existing order remains consistent, with no duplicate fulfilment.
Keep the gateway version in your test record. The extension’s published release notes include fixes for completing 3D Secure payments under particular Optimized Checkout configurations and separating cached test and live connection data. Check released fixes against your installed version; a proposed change or open issue is not a deployed repair.
Test evidence should connect the checkout result, Stripe reference, received event and final order state. A screenshot of the thank-you page is only one part of that evidence. After deployment, confirm the live connection and monitor the next genuine orders through the same sequence.
Give payment mismatches an owner
As an operating check, compare successful gateway payments with the store’s paid orders at a frequency that suits your dispatch schedule. Investigate unmatched payments and unexpectedly old pending orders. Set expectations separately for payment methods that genuinely take longer.
Assign responsibility for that review and for customer updates. A retailer should discover a stalled paid order before the customer has to chase it.
If your checkout takes payment but the handover to orders or fulfilment is unreliable, our web development and integration work can help connect the investigation across those systems. Contact BuzzBoost to discuss the affected checkout route and the evidence you already have.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
