Stripe payment succeeded, but WooCommerce still says “Pending payment”?

Stripe shows a successful payment. In your store, the same order is still awaiting payment or has already been cancelled. Before asking the customer to pay again or releasing the order for fulfilment, you need to match the payment to the order conclusively. This guide helps you understand the conflicting statuses and preserve the evidence that matters.

One documented case involves Adaptive Pricing in the official WooCommerce Stripe Gateway: payments were processed successfully while the associated orders remained pending. The report identifies gateway versions 11.0.1 and 11.1.1 and missing order references in the PaymentIntent. It documents a specific failure sequence; it does not establish that every installation is affected. Q1

Does this guide match your issue?

Start with these four questions:

• Is there a specific WooCommerce order and a matching Stripe payment?
• Do the amount, currency, time and live or test environment match?
• Does the Stripe PaymentIntent actually have the status succeeded?
• Does the order nevertheless remain “Pending payment”, or was it subsequently cancelled?

If the Stripe payment shows requires_capture, the amount has initially been authorised. That is different from a completed payment. Likewise, processing does not mean the outcome is final. A successful SetupIntent sets up a payment method; it does not prove that the order has been paid. Q6

Also check the amounts and any later activity: requires_capture can be associated with a partial capture. A PaymentIntent may continue to show succeeded after a refund; subsequent changes need to be checked on the payment object or in the Dashboard. The status alone is therefore not a complete reconciliation of the money received and returned. Q7

Why the payment and order can become disconnected

Processing the payment and updating your order are separate steps. Diagnosis therefore requires both the Stripe record and evidence of what your store processed. A green connection indicator or a successful HTTP response cannot replace that comparison.

In the Adaptive Pricing case reviewed here, certain payment events received HTTP 200 responses even though the order was not matched. The webhook subscription was also missing checkout.session.completed. This explains why “webhook delivered” and “order updated correctly” need to be checked separately. Q1

For your own case, compare three stages side by side: the payment, delivery of its event, and the order notes. Find the first stage where an unambiguous link is missing. That turns “Stripe is not working” into a question you can investigate: is the payment still incomplete, is an event missing, or is the store handling an event without a matching order?

First steps: preserve a clear record of one affected order

1. Start with one specific order. Record the order number, status, amount, currency and timestamp, including the time zone. Choose a transaction that is clearly affected. A complete customer database is not useful for this initial check.

2. Check the payment status directly in Stripe. Record the PaymentIntent ID, the Checkout Session ID if applicable, and the displayed status. Make sure you are viewing the correct account and the correct live or test data. Use placeholders in material shared publicly; access keys do not belong in a support form.

3. Compare the order notes. Is there a transaction reference? When was the order created, last updated or cancelled? Record discrepancies without changing the status yet. The original event sequence is more useful for investigation than a record that has already been “cleaned up”.

4. Check which checkout flow was actually used. Document the Adaptive Pricing setting in the gateway separately from the setting in the Stripe account. In the original case, changing the Stripe Dashboard setting was initially insufficient because the plugin setting also needed to be considered. Q1

5. Check delivery of the specific event. Which event ID belongs to the payment? Which endpoint received it? What response status was returned? Is the required event type subscribed to? WooCommerce documents separate live and test connections and a function for reconfiguring webhooks. Follow the instructions appropriate to your installed version; do not delete endpoints used by other integrations. Q4

6. Compare the store logs. The Stripe Gateway troubleshooting guide explains error logging and how to match records using order and payment references. Preserve a limited period around the incident, including the time zone. If logging was not enabled for the earlier incident, record that gap in the evidence. Q5

7. Decide what to do with the individual order only after reconciliation. For a confirmed payment, establish which order should be fulfilled and whether a refund or other action has already taken place. For an authorisation alone, first check the intended payment flow. Changing every pending order in bulk is not an appropriate way to resolve this.

Has a fix been released?

As of 4 November 2026, the proposed recovery approach in PR #5634 was still open and assigned to the 11.2.0 milestone. The official plugin directory listed Stripe Gateway 11.1.1, dated 16 October 2026. A target version attached to a development task is not a released fix. Q2 Q3

For your installation, first record the version of the Stripe Gateway. The version number of WooCommerce itself does not answer that question. Before updating, check the actual changelog and whether the changes apply to the relevant payment method. A successful test also does not replace reconciliation of orders that have already been affected.

Frequently asked questions

Should the customer simply pay again?

Check the existing payment first. While its outcome remains unclear, another payment creates more reconciliation work. If the payment succeeded, any further action should refer to that transaction.

Is an HTTP 200 webhook response enough to rule out a problem?

No. The documented case included successful HTTP responses without the corresponding order status update. What matters is whether this particular payment was matched to this particular order and processed correctly. Q1

Can I set all affected orders to “Completed”?

That would not be a reliable diagnosis. Check each order’s payment status, matching references and any action already taken. Payment reconciliation and fulfilment decisions belong together; the same order status is not automatically appropriate for every product or business process.

Would disabling Adaptive Pricing help?

It may be useful as a targeted comparison test, documented in advance. It does not retrospectively match older payments to orders. Check the relevant setting and test a defined flow instead of changing several checkout options at once.

Why is requires_capture not reliable confirmation that payment has been received?

This status indicates that capture is still outstanding after authorisation. With succeeded, the PaymentIntent payment flow has completed successfully. Make this distinction before deciding what to do with an order that appears to have been paid. Q6

What information is useful in a support request?

Include the gateway version, checkout flow, affected period and the two statuses you see. Add a sanitised log excerpt and an anonymised mapping between the order, PaymentIntent and, where applicable, Checkout Session. Customer names, card details and secret keys are not required.

Describe your issue

Explain what Stripe shows, what WooCommerce shows, and which change preceded the discrepancy. One clearly documented order is a useful starting point. It helps establish which connection needs to be checked next and what information is still missing.