One cart became two store orders

Compare two records before choosing the survivor

Open both actual orders and compare their creation times with time zones, items and variations, quantities, totals, currency, payment method and gateway notes. Check whether either has already entered fulfillment. Record the buyer's statement that only one purchase was intended as a report to reconcile, not as proof that either payment failed.

The earlier order is not automatically the valid one, and the later order is not automatically the duplicate. A later attempt may be the one that completed payment. Matching names or billing emails help locate the records but do not establish the intended number of purchases or the payment result. Verify those details within your normal authorized customer-support process.

The current WooCommerce order-status documentation says block checkout can reuse an eligible pending or failed order already in the customer session. A fresh block checkout creates its draft at Place Order. Therefore, a second click does not invariably create a second store order. Two visible records need an explanation from the actual checkout and gateway history, not an assumption about all WooCommerce versions or plugins.

The payment reference determines which comparison you have

Compare like references within the same provider account. A store order number, a payment-flow identifier and a charge identifier can describe different objects. If the two notes expose different kinds of reference, ask the gateway owner to trace them to the underlying payment before counting payments. Record the provider object type beside the identifier in your private comparison.

If both orders refer to one verified successful payment, do not fulfill both merely because both store statuses look paid. Establish which order correctly represents the intended purchase and already has any fulfillment handoff, then have the integration owner resolve the duplicate association. Preserve a cross-reference between the records so later support does not treat them as separate paid sales.

If there are two distinct payment objects, inspect each state. For a Stripe PaymentIntent, succeeded means that payment flow completed; requires_capture means separate authorization and capture is in use and capture is still required. Processing can represent an asynchronous method that takes days. A succeeded SetupIntent saves payment credentials and is not payment for an order. These are Stripe object meanings, not translations of every gateway's order notes.

One completed payment and one confirmed unsuccessful attempt support keeping the correctly linked paid order and considering cancellation of the unwanted unpaid one. Two successful payments require a decision about the unintended paid order and any payment remedy through the provider's documented process. Neither order should produce an extra shipment while that decision is unresolved. No successful payment, or a still-processing or uncaptured payment, does not support fulfillment from either store label alone.

A duplicate order and a duplicate request need different repairs

Stripe's idempotency documentation explains protection for repeating the same API request with the same idempotency key: Stripe returns the saved result. A separately keyed request is outside that original protection, and reuse after a key has been pruned creates a new request. Stripe permits removing keys once they are at least 24 hours old. That duration is not a guarantee that every plugin preserves one checkout identity or retains a key forever.

This mechanism cannot prove that your gateway sent a particular key, or that two WooCommerce records represent two payment requests. The integration owner needs the real request history to establish whether the checkout created another order, made another payment request, or attached one payment to two records. A second click, a slow response or an automatic retry is an investigation lead only when it appears in that history.

Keep the order-disposition decision separate from the repair. Staff can reconcile and document the affected pair while the developer investigates how the pair arose. Do not ask the buyer to pay again or create another payment to reproduce the problem.

Reconcile inventory and fulfillment when retiring the duplicate

WooCommerce Processing and On hold orders have stock reduced. Pending orders can instead have checkout stock reserved. A transition to Failed returns stock that was previously reduced, and Cancelled returns line-item stock when inventory management is enabled. Cancelling the unwanted order therefore has an inventory consequence to check, even when it has no successful payment.

Record which order reduced or reserved which quantities, whether a shipment or warehouse handoff already exists, and which record will remain the fulfillment record. After an authorized cancellation, check the actual inventory result before any manual adjustment. Do not delete the comparison or increase stock a second time because the duplicate looked unpaid. External inventory or warehouse systems require their own confirmation.

A WooCommerce cancellation does not prove that an authorization was released or captured money was refunded. If money moved on the unwanted order, retain its payment history and document the separate resolution. For a Prism checkout-review consultation, summarize whether the pair involved one payment, two payments or an unresolved reference, and the checkout involved. Scope, responsibilities, fees and terms need agreement before implementation work. Keep customer details and credentials out of the public inquiry.

Duplicate-order comparison

Use one worksheet for the two real store orders. In the blank column record both order references and their readings, then the selected disposition. Keep identifiers inside your authorized records; summarize email and identity comparisons as match, mismatch or unverified without copying personal data. A reference mismatch must be resolved before the keep/cancel decision.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.