How to Diagnose Paid Orders That Remain Pending or Create Duplicate Purchases

Separate the Four States Before Diagnosing the Fault

Use four separate observations: provider payment state, shop order state, fulfilment state and customer-facing confirmation. “Successful checkout” is too vague to identify which one has been verified. A confirmation email, a paid order label and a payment reference are different records that need to agree.

For Stripe PaymentIntents, requires_action means further customer action is needed; processing can mean the result remains unresolved; requires_capture indicates an authorised payment awaiting capture; succeeded means that payment flow completed. Read the provider’s current state rather than translating every bank notification into “paid”. A successful SetupIntent saves payment credentials and is not evidence of a purchase payment.

The browser return is the customer’s route back to the shop. A webhook is a provider-to-server notification. Stripe’s Checkout documentation explains why automated fulfilment cannot rely only on the return page: a customer may pay and never reach it. The return page can help display the result, but its absence should not be the sole reason a confirmed payment is overlooked.

Shop labels require their own definitions. “Pending” may mean waiting for payment, awaiting review or waiting for another business step. Ask which transition should occur for the selected method and who owns it. Do not report a fault solely because two platforms use different words.

Choose the Investigation From the Evidence

These interpretations narrow the investigation; they do not identify the faulty line of code. A missing order update could involve a failed notification, an unmatched reference, a rejected business rule or an application error. Collect evidence at each boundary before assigning the cause.

Pause the diagnosis if the payment and order cannot be matched reliably. An equal amount and similar timestamp are not enough in a busy shop. Ask for the stored relationship between the checkout attempt, provider object and order. Mark the conclusion unresolved until that relationship is supported.

Where payment is confirmed but an order remains unresolved, the next step is an authorised reconciliation review. Where the order is correct and only the return page fails, prioritise the misleading customer message. Both problems matter, but they require different acceptance tests.

Prepare a Test That Cannot Affect Real Orders

Confirm the shop environment, provider account, test credentials and notification destination together. A staging hostname alone does not establish isolation. The integration owner should also check stock synchronisation, warehouse exports, email delivery and other downstream connections before a synthetic order is submitted.

Stripe’s testing guidance uses simulated transactions that do not move funds and requires test API keys for test cards. It says not to use real card details for testing. Use the provider’s current test values for the required outcome; do not copy customer payment details into a test script or issue report.

Agree the expected result before each run. State whether an unpaid order is created before payment, what counts as payment confirmation and which order transition should follow. Identify the expected stock, dispatch and notification effects. This prevents a perfectly normal unpaid attempt being mistaken for a duplicate purchase.

Record the build, payment plugin version and relevant configuration. Use one synthetic basket and a new test-run reference for each independent scenario. A retry within the same scenario should remain connected to its original attempt, so the evidence shows whether the shop treated it as a continuation or a new purchase.

Build a Payment-to-Order Timeline

The timeline should connect observations across the browser, provider and shop without relying on personal details. Include the following fields in the test record:

• Identity: run reference, checkout attempt, order reference, provider payment or session reference, event reference and delivery attempt.
• Context: test environment, gateway, method, amount, currency, build and relevant plugin configuration.
• Time: action time, provider event time, receipt time and application completion time, with time zone stated.
• State: provider status, order status before and after processing, and any fulfilment effect.
• Evidence: source of each observation, such as provider record, application log, order history or browser recording.
• Conclusion: expected result, observed difference, unresolved question and next owner.

Keep event creation, delivery and processing times separate. Log clocks may differ, and an event can be generated before the shop receives it. Record known clock differences rather than rearranging entries to make a preferred explanation appear correct.

A successful HTTP response from a webhook endpoint is not, by itself, evidence that the intended order update finished. Trace the application result and any queued job separately. Conversely, a missing browser confirmation does not prove that the server failed. The timeline should make those gaps visible.

Keep the provider’s webhook authenticity checks enabled. For Stripe, verify the event signature before acting on a notification; do not bypass verification merely to make a failing test pass.

Use restricted evidence storage. Exclude card details, credentials, signing secrets and unnecessary customer information from screenshots and reports. Synthetic references are usually sufficient to explain a reproduction. A developer can inspect sensitive operational evidence through the business’s approved access route.

Run Scenarios That Distinguish the Failure Paths

Establish a normal successful checkout

Complete one ordinary sandbox purchase. Record the expected payment and order states, browser result and downstream actions. Check the actual saved records instead of accepting a green success message as the whole result. This baseline provides a comparison for the interrupted and repeated paths.

Interrupt the return after confirmed test payment

Use an agreed test arrangement to prevent the browser reaching the shop’s return page after the provider confirms success. Record exactly where the interruption occurred. Closing a tab before payment confirmation tests a different situation and cannot establish that a successful payment was lost.

Check the order independently in the test administration area. If the order updates correctly, the absent return did not prevent processing in that run. If the order stays pending, inspect the notification and application evidence. Do not immediately conclude that the return page was responsible.

Check decline, incomplete authentication and delayed completion

Use documented simulations for the methods the shop supports. Confirm that unresolved or declined payments do not receive a misleading paid confirmation. A later successful result should be reconciled with the correct attempt. Record expected waiting behaviour and the point at which investigation becomes necessary for that integration.

Repeat a notification and a browser action separately

With the developer, resend a relevant sandbox event to the isolated endpoint. In a separate run, revisit or refresh the return page. Compare payment, order and fulfilment counts after each action. Keeping the two scenarios separate helps identify which entry point can repeat a business effect.

Stripe documents that notifications can arrive more than once and that delivery order is not guaranteed. Its guidance distinguishes a repeated event ID from separate events concerning the same object and event type. The developer must check the relevant business operation as well as whether an event has been seen before.

Examine a customer retry without assuming it is harmless

In the isolated environment, reproduce the exact retry route: pressing Pay again, returning through browser history or restarting checkout after an error. Record whether the shop reuses the intended purchase or creates another attempt. A second attempt is not automatically a second completed payment; compare the provider outcomes.

Stripe API idempotency keys support retrying the same request without repeating that operation. They do not automatically prevent duplicate shop orders, emails or warehouse jobs. Ask the developer to demonstrate protection at the order and fulfilment boundaries, including concurrent calls. A disabled button alone is not evidence that those boundaries are protected.

Worked Example: The Payment Succeeds but the Order Stays Pending

Synthetic example: all references, times, amounts and observations below are invented to demonstrate the record. No payment was made and no client test result is being claimed. The hypothetical shop creates an unpaid order before a sandbox card payment and should mark it paid after verified confirmation.

Run TEST-017-A uses basket BASKET-A, order ORDER-A and provider payment PAY-A for £24.00 GBP. These are explanatory labels, not real provider identifiers. The browser return is deliberately interrupted after success. All times use UTC.

The supported conclusion is narrow: this fictional notification reached the shop, but its queued processing failed before the order update. The interrupted return is part of the scenario, not proof of the cause. The developer needs to inspect the job failure and demonstrate a controlled recovery without another collection or duplicate fulfilment.

For the recovery check, record which existing payment and order are reused, the recovered job’s result and the final state. Then repeat the relevant notification and return-page scenarios. Acceptance requires one intended paid order and only the intended fulfilment effects for this single-item example.

A contrasting case has a provider payment still processing and no success confirmation. A pending shop order may be appropriate there. Another case has no application logs at all: a delivery receipt and pending order justify investigation, but not a claim that the worker failed. Record the missing evidence instead of copying the example’s diagnosis.

Distinguish a Duplicate Record From a Duplicate Purchase

For one intended purchase, count separate objects rather than screenshots. Two order numbers with one confirmed payment indicate an order-record problem if both represent the same purchase. One order with two confirmed collections raises a payment-retry problem. One paid order with two dispatch jobs raises a fulfilment problem.

Check whether apparently repeated records are legitimate parts of the integration. An unpaid attempt, a parent order and its split shipments may be intentional. Ask the owner to explain the expected relationship. Document the unexpected repeated effect rather than labelling every extra row a duplicate.

Do not delete one order simply to make the counts agree. The payment reference, stock movement or dispatch relationship may depend on it. A correction should be approved by the responsible owner, retain the necessary history and be followed by a test of the path that created the discrepancy.

Mistakes That Hide the Cause

• Changing several settings before recording a baseline: the next result cannot show which change mattered.
• Matching by email and amount alone: separate legitimate purchases can look similar.
• Marking the order paid manually and closing the issue: the original processing fault may remain.
• Checking only the provider dashboard: a confirmed payment does not demonstrate correct stock or dispatch handling.
• Treating an HTTP success response as completed work: verify the saved order transition and downstream result.
• Using analytics purchase counts as payment evidence: keep reporting discrepancies separate from operational payment records.

Retest the Boundaries After a Fix

Agree a small regression set covering normal success, declined or unresolved payment, interrupted return, customer retry and repeated notification. Add concurrent processing where the developer can test it safely. Record which scenarios passed on the fixed build and which supported methods remain untested.

Define monitoring with the shop owner: confirmed payments lacking the expected order state, unexplained duplicate relationships and failed processing jobs are useful exception categories. Set review timing from the actual payment methods and operational process. A universal “pending for five minutes” rule would be inappropriate for every integration.

Repeat relevant checks after payment-plugin changes, checkout changes and changes to order or fulfilment integrations. Keep the expected state mapping with the test record so a future tester can distinguish an intentional workflow change from a regression.

If the problem extends into the wider checkout journey or platform constraints, a review of checkout routes and conversion barriers can help scope those concerns. Keep that broader review separate from the evidence needed to resolve a specific paid-but-pending order.

How to Get This Done

Give the investigator a reproducible sequence, synthetic references, the expected state transition and evidence from each available boundary. Include the environment, payment method, plugin version, timing and whether the browser returned. State explicitly which records were unavailable and whether any real customers are affected.

Request a diagnosis that identifies the failed boundary, the evidence supporting it and the proposed acceptance tests. The brief should distinguish investigation, development work and any authorised incident correction. Payment retries, refunds and live order changes need their own controlled handling.

The manual website fault investigation offered by KAP SEO Services includes checkout-journey and conversion-flow testing. Use the evidence to establish what needs developer or payment-provider attention, with implementation responsibilities agreed rather than assumed.