WooCommerce and Stripe: customer charged twice after a checkout error?

Two payment entries, two orders, or an error message after payment: first establish whether money was actually captured twice. Then investigate why the same cart could be processed again. Any refund or checkout change should be based on that reconciliation.

A public WooCommerce report describes duplicate successful Stripe payments alongside HTTP 499 responses to checkout requests. According to a later reply, another incident occurred without any error visible to the customer; the server data suggested overlapping requests. What the customer saw is therefore not enough to establish the full sequence. Q1

First distinction: two payments or two entries?

Compare four pieces of information for the affected purchase:

• the WooCommerce order numbers;
• the associated PaymentIntent and payment references;
• the amount, currency and timestamp;
• the actual status of each payment.

requires_capture initially means that an authorised payment still needs to be captured. A pending authorisation must not automatically be counted as a second completed payment. Stripe describes authorisation and capture as separate steps. Q5 Q6

A partial amount may already have been captured. Check the captured amount, the amount still authorised and the amount already refunded separately. A PaymentIntent that continues to show a successful status also does not rule out a subsequent refund; check these later changes on the payment object or in the Dashboard. Q5

Two orders alone are not proof of an unwanted duplicate payment either. WooCommerce recommends comparing payment information and order notes and clarifying what the customer intended to buy. Two deliberately separate purchases need to be handled differently from an accidentally repeated order. Q4

What HTTP 499 means for the investigation

In the report reviewed here, HTTP 499 occurred on POST /?wc-ajax=checkout. The vendor’s reply describes this as a connection interrupted before the checkout response had fully reached the browser. It does not prove that no payment had already been processed. Q1

Your case therefore needs a timeline: when did the first checkout request start? When did the payment succeed? When was the response connection interrupted? When did another attempt begin? Investigate this sequence before attributing the incident to a customer double-click or a payment provider error.

A slow request, an interrupted response and the creation of a second payment are three different observations. If their timestamps and references line up, they can support a working hypothesis. Without matching references, an unusual server log entry may belong to an entirely different transaction.

How to investigate one specific incident

1. Preserve the original state. Record the affected orders and their payment references. Include any cancellations or refunds already made so that the same payment is not accidentally processed a second time.

2. Check both transactions in the correct Stripe account. The status of each payment matters, rather than the number of notifications. Record whether the amount was captured, only authorised, failed or has already been refunded. Stripe provides payment status information in the Dashboard and at PaymentIntent level. Q5

3. Clarify which order is intended. Which order should remain? Was only one purchase intended? Which goods have already been shipped, or which digital access has been granted? Document this decision before cancelling an order or refunding a payment.

4. Match the server records. Ask the person responsible for hosting for the checkout requests within the relevant, limited time window, including their start times, duration, response statuses and any request IDs. Do not publish cookies, session data or complete customer details. Missing shared identifiers remain a gap in the evidence.

5. Describe the exact checkout flow. Record whether the checkout is classic or block based, whether the payment method was saved or newly entered, whether Adaptive Pricing was involved, the device used and the observed sequence. “After payment” is not specific enough for a comparison test.

6. Test changes individually. Record the gateway version, WooCommerce version and recent checkout changes. Use an isolated environment and test payments for testing. Do not create duplicate real charges simply to confirm the fault. WooCommerce explicitly highlights the separation between staging and production. Q4

7. Separate incident resolution from prevention. Reconciling an existing duplicate transaction does not prevent another one. Conversely, a later plugin update does not automatically reconcile older payments correctly. Each task needs its own evidence of completion.

What protection has the vendor prepared?

PR #5988 was merged into the development branch on 22 October 2026. It describes a lock on the same cart while payment is being processed, followed by a redirect to the order that has already been paid. Its scope is limited: Adaptive Pricing Checkout Sessions and “Pay for order”, among other flows, are excluded. Q2

When checked on 4 November 2026, the official plugin directory still listed Stripe Gateway 11.1.1, dated 16 October. Support identified 11.2.0 as the planned release for this protection. A merged development change therefore does not establish that a version installed from the plugin directory already includes it. Q1 Q3

Before updating, check which version has actually been released and what it covers. In particular, do not assume that every different checkout flow receives the same protection. Testing your own flow remains essential.

Frequently asked questions

Do two emails prove that the customer was charged twice?

No. Match both messages to their orders and payment references. The actual payment statuses are what matter. The number of emails is only a starting point for investigation.

Can I refund the second entry immediately?

First check whether it represents a completed payment, an authorisation or a payment that has already been handled. Also establish which purchase should remain. Refunding solely on the basis of a timestamp or matching amount can affect the wrong transaction.

Must the customer have clicked twice?

That cannot be inferred from the outcome. The later documented incident involved overlapping requests even though the customer had not noticed an error. Reconstruct the request sequence instead of assuming a particular customer action. Q1

Could a second unpaid order still appear with the protection in place?

Yes. In its description of the proposed protection, the vendor explains that a blocked parallel request can leave a pending order behind. The protection is intended to prevent an additional payment. “No second order” would therefore be unsuitable as the sole acceptance criterion. Q2

Should I simply increase the server timeout?

First establish where time is being spent and which connection is being interrupted. Changing a timeout without measurements does not explain why multiple payment attempts occurred. Then compare a defined flow before and after a targeted change.

What information is needed for a technical review?

Useful information includes two anonymised order-to-payment mappings, payment statuses, timestamps with the time zone, the gateway version and matching server log entries. Add whether the customer clicked again, reloaded the page or noticed no error at all. “Unknown” is a useful answer too.

Describe your issue

Explain whether you have identified two actual payments, two orders or, so far, only two displayed entries. Include the sequence of events and sanitised references. This lets the investigation start with the right question: payment reconciliation, duplicate checkout processing, or a displayed entry whose meaning is still unclear.