Stripe Says Paid, WooCommerce Says Pending: A Safe Reconciliation Checklist

Reconciliation of payment data requires treating both the WooCommerce and Stripe platforms as distinct, authoritative data sources rather than assuming one system’s state is universally correct. Engineers must avoid the impulse to manually update order statuses upon identifying a discrepancy, as this can trigger premature fulfillment or redundant financial processing before the cause of the drift is understood.

Before initiating any corrective action, capture a comprehensive snapshot of the transaction state from both endpoints. This data serves as the baseline for your investigation and must be handled with strict adherence to security standards—never include PII (Personally Identifiable Information), full card details, API keys, or webhook secrets in logs or support tickets. Collect the following metrics for objective analysis:

• WooCommerce Baseline: Record the current order status, associated timestamps, and entries from the order notes.
• Stripe Metadata: Identify the specific PaymentIntent or charge reference linked to the order. Verify the object's current status (e.g., succeeded, requires_capture) and ensure both systems reside in the same operational mode (live versus test).
• Financial Normalization: Extract gross amounts and currencies. To ensure accuracy, convert all monetary values into the smallest unit (e.g., cents) and compare against authoritative Stripe data rather than formatted string representations.
• Audit Trails: Document webhook-delivery timestamps and verify the event history within the Stripe dashboard.

When analyzing these records, confirm the identity of the transaction across systems. Retries and multiple checkout attempts can often cause a single WooCommerce order to reference a stale or superseded PaymentIntent. Furthermore, distinguish between system logs and network responses; a successful HTTP 2xx response from a webhook endpoint indicates connectivity but does not confirm that the downstream order processing logic successfully reached a terminal state.

By automating the comparison of these data points in a read-only manner, you create a diagnostic layer that identifies inconsistencies without introducing new financial failure surfaces. Only after validating the identity, amount, and history of a transaction should an engineer determine whether a manual update or a status transition is appropriate.

Content generation failed for this section.

A webhook delivery history is Stripe’s record of every attempt to send a given event to a registered endpoint. When a PaymentIntent is successful but the WooCommerce order is not updated, begin by locating the Stripe event associated with that exact PaymentIntent or charge and reviewing its delivery history. This establishes what Stripe sent, where it was sent, and how the destination responded.

For each delivery attempt, check the full path:

• Expected endpoint: Confirm the event reached the URL currently configured in WooCommerce Stripe settings. A stale, duplicate, or test-mode endpoint can receive deliveries while production order updates continue to fail.
• Response code and time: Inspect the HTTP status code returned by your server. An HTTP 2xx means the endpoint accepted the request, but it does not prove the downstream order update finished. Also record response time; high latency may point to proxy buffering, slow plugins, or blocked background work.
• Retry behavior: Stripe retries failed deliveries. A later retry may have succeeded after an initial timeout or 4xx/5xx response. Check whether the first failure was followed by a successful retry before concluding that the order was never updated.
• Interception: Determine whether a proxy, WAF, cache layer, maintenance mode, or security rule modified, delayed, or blocked the request before it reached the WooCommerce webhook handler. A cached response or a filtered header can make delivery history look successful even when the payload was not processed.

After reviewing Stripe’s records, examine the same timestamp in WooCommerce Stripe logs, PHP error logs, and server access or error logs. Look for exceptions raised after the endpoint accepted the payload; a fatal error in the webhook callback can produce a 2xx response while leaving the order status unwritten. An HTTP 2xx is useful evidence that the webhook was received, but it is not proof that the order notes, status transitions, and downstream integrations completed successfully.

When reconciling transaction data between WooCommerce and Stripe, engineers must avoid comparing display-formatted strings. Strings such as "$149.00" and "149" are ambiguous representations of financial state; relying on them for validation frequently leads to false positives during data drift analysis. To ensure mathematical accuracy, all financial comparisons must occur at the integer level after normalization.

The normalization process requires shifting from decimal-based display formats to the smallest unit (e.g., cents for USD, yen for JPY) defined by the currency’s ISO 4217 standard. This eliminates floating-point arithmetic errors and inconsistencies caused by locale-specific formatting. Follow these technical guidelines for robust value comparison:

• Convert to Base Units: Transform the WooCommerce order total into the smallest unit used by the currency (e.g., multiply USD amounts by 100). Compare this integer directly against the amount field retrieved from the authoritative Stripe PaymentIntent or charge object.
• Standardize Currency Codes: Perform case-insensitive comparisons of ISO 4217 currency codes. Treat "usd" and "USD" as equivalent to prevent failures resulting from inconsistent string casing across different API integrations.
• Validate Refunded Totals: Only compare refund data when the Stripe object explicitly provides an authoritative refund state. Ensure that the logic accounts for partial refunds by verifying both the total and the current state against the Stripe API response, rather than relying on internal WooCommerce order notes alone.

While strict normalization is mandatory for identifying discrepancies, engineers must recognize that a mismatch does not inherently prove that Stripe processed the incorrect amount. Data drift often originates from environmental factors rather than core payment failures. When investigating differences, consider the following sources of discrepancy:

• Manual Order Edits: Post-checkout modifications to order items or shipping costs in WooCommerce may not be reflected in the original Stripe payment object.
• Integration Failure: Mid-process exceptions or server-side logs might indicate that an update to the order status failed even if the financial transaction was successfully captured.
• Asynchronous Flows: Unusual capture flows, manual captures, or retries following a failed initial attempt can decouple the WooCommerce order state from the authoritative record on Stripe’s servers.

Reconciling payment states requires distinguishing between transient integration artifacts and terminal financial outcomes. Enterprise engineers should categorize discrepancies by pattern to avoid automated, erroneous remediation.

• Stripe succeeded but WooCommerce remains unpaid: This pattern typically indicates a failure in the asynchronous update pipeline. Verify the provider object ID matches the order record. Inspect order notes for processing errors, review the Stripe webhook delivery history for non-2xx responses, and analyze server-side PHP or application logs for exceptions occurring between the webhook receipt and the final database status write.
• WooCommerce claims paid but Stripe reports terminal failure: A discrepancy here often stems from a race condition or a stale reference. Confirm whether the user initiated a secondary checkout attempt. Search the Stripe dashboard for a later retry or a replacement PaymentIntent that succeeded. Concluding an order is unpaid based on an initial failed attempt ignores the reality of multi-attempt checkout flows.
• Refund totals differ: Disparities in refund states are usually attributable to multi-channel intervention. Determine where the refund was initiated—the WooCommerce dashboard, the Stripe dashboard, or an external ERP/CRM. Check if both systems have successfully processed the most recent update. Always compare normalized financial values (smallest currency unit) rather than formatted strings.
• No usable Stripe reference: Treat missing identifiers as an identity problem rather than a payment-status conclusion. Investigate the order creation source to determine if the transaction originated from a legacy gateway, an alternative integration, or a manual administrative entry. Do not attempt to force a status update until the provenance of the payment record is established.

Adopting an observe-correlate-verify workflow ensures that diagnostic steps remain read-only. Avoid automated state changes, as they can trigger unintended fulfillment flows or duplicate financial processing before the underlying data drift is reconciled.

Payment reconciliation should begin as an evidence problem, not an order-status problem. A WooCommerce status label and a Stripe dashboard row are both evidence; neither is complete alone. Before any change, record the WooCommerce order status and timestamps; the exact Stripe PaymentIntent or charge reference stored on the order; the Stripe object’s current status; gross amount and currency in both systems; refunded total in both systems; relevant order notes; and Stripe event and webhook-delivery timestamps. Never paste customer data, card data, API keys, webhook secrets, or full payment identifiers into a public support thread.

A comparison is useful only when both records refer to the same transaction. Confirm that:

• the Stripe object ID on the order resolves to the object you are viewing;
• the WooCommerce gateway and the Stripe object use the same test or live mode;
• the store is connected to the same Stripe account that originally created the payment;
• a retry or second checkout attempt did not create a newer PaymentIntent.

If the reference is missing or points to another account or mode, stop. The provider read is not authoritative for that order until the identity problem is resolved.

Payment updates are not always synchronous with the browser returning from checkout. Webhooks, redirects, background actions, and retries can complete at different times. Use a short grace period before calling a status difference an incident; five minutes is a practical starting point for automated comparison. Inspect the full webhook path in Stripe: find the event for the exact PaymentIntent or charge and review delivery history, response codes, retry success, intercepting proxies, and gateway or server logs at the same timestamp. An HTTP 2xx response is useful evidence but does not prove every downstream order update finished successfully.

Compare normalized financial values, not formatted strings. Convert the order total to the currency’s smallest unit and compare it with the authoritative Stripe amount for the exact object. Compare lowercase ISO currency codes. Compare refund totals only when Stripe provides authoritative refund data. Amount or currency differences deserve investigation but do not automatically prove Stripe charged the wrong amount; manual edits, unusual capture flows, retries, and integration failures can also produce data drift.

Build a bounded, read-only scan over recent Stripe orders that reports:

• status disagreements after a grace period;
• gross amount or currency mismatches;
• refund-total mismatches;
• stale pending orders;
• missing or unreadable Stripe references.

Keep the first version read-only. Automatically changing order state, replaying webhooks, capturing funds, or issuing refunds turns a visibility tool into a financial-action system with a much larger failure surface. A mismatch is a prompt to investigate, not a repair instruction. Before fulfillment or a financial change, confirm the exact payment, the amount actually charged, whether a newer event or retry exists, whether order notes and logs support the intended state, and whether another integration will repeat or reverse the manual action. Document the evidence and the action taken so the next incident is easier to diagnose.