Notifications are counted as operations
Several events can describe the same payment. Counting them independently inflates the amount you believe was collected.
Stripe · Payment mechanics for reconciliation
How Stripe Payments Map to WooCommerce Orders
This guide covers one mechanism: how a WooCommerce order points to Stripe objects and which Stripe numbers belong in an order-level comparison. For a reconciliation routine across all payment methods, see WooCommerce payment reconciliation.
Why Stripe reconciliation can look wrong
Many apparent differences come from mixing identifiers or accounting scopes.
Authorized and captured amounts are confused
A payment can be authorized before collection; the captured amount may also differ from the original authorization.
Payout net is compared with order gross
Fees, settlement timing and unrelated payments make a bank deposit unsuitable as an order capture amount.
From the order to the payout: the Stripe objects
Read the chain from top to bottom. Only the charge and its refunds belong in an order-level comparison.
| Object | Where you see it | What it means for reconciliation |
|---|---|---|
| WooCommerce order | Order notes (“Stripe charge complete”), transaction ID, PaymentIntent in the order meta | The shop’s view and the starting point of the trail |
| PaymentIntent pi_… | Stripe Dashboard → Payments | One checkout; can hold several attempts (a declined card, then a success). Count only the successful charge |
| Charge ch_… / py_… | Payment details → latest charge | Captured amount and refunded amount — the numbers to compare with the order |
| Refund re_… | Payment details → Refunds | Compare with each refund in WooCommerce |
| Balance transaction txn_… | Balance → Transactions | Net after the fee, in the settlement currency — not the order amount |
| Payout po_… | Balance → Payouts | Sum of many balance transactions — bank reconciliation, not order reconciliation |
Example: a partial capture
An order paid with manual capture, captured for less than the authorized amount.
Order and Stripe side by side
Order #5120 total 240.00 EUR · Processing · PaymentIntent pi_3QB…
Stripe pi_3QB… authorized 240.00 EUR (manual capture)
Stripe ch_3QB… amount_captured 200.00 EUR · 40.00 EUR released
Stripe txn_… net 196.75 EUR · fee 3.25 EUR
Payout po_… 3,418.55 EUR on Friday · 41 payments, 2 refundsIllustrative sequence: identifiers, amounts and times are made up; the formats follow WooCommerce order notes and the providers’ dashboards. No customer data.
What this shows
The order says 240.00, the buyer paid 200.00 — that is the difference to review (an item out of stock?). The 3.25 fee and the 3,418.55 payout do not explain it; they belong to a different check.
Build a Stripe reconciliation trail for one order
- Select the WooCommerce order, Stripe account, mode and currency. Obtain the gateway reference and resolve its PaymentIntent and related Charge.
- Inspect the captured amount rather than the authorized amount. If capture happened in stages, review the cumulative captured amount and history.
- Check refunds against the same payment. Verify whether each WooCommerce refund has independent evidence and whether extra provider refunds exist.
- Record unresolved matches separately. Investigate processor fees and bank payouts outside the order capture comparison.
Official references for the checks above:
Correct matching before correcting money
Resolve the confirmed cause
Repair a missing reference or delayed import before deciding there is a financial discrepancy. If a real difference remains, review the order revision and the actual provider operations; choose a correction through the appropriate store or provider workflow.
Verify the result
Repeat the comparison with fresh data. A duplicate event must not increase the captured amount, and a fee must not become an underpaid order. Verify refunds independently even if the net totals happen to agree.
How Business Watchdog reconciles Stripe with WooCommerce
Business Watchdog reads Stripe with a restricted key, resolves supported payment references and checks captures and refunds against WooCommerce. Its Stripe multicapture handling follows the Charge’s captured amount rather than inventing another capture from each repeated event.
- Order and payment data are compared only within the connected, supported coverage.
- Missing or stale data is shown as incomplete, not as a healthy result.
- Alerts can be delivered by e-mail or Telegram when the corresponding supported rule applies.
Where the coverage stops
This does not reconcile bank payouts or cover every Stripe product. Unsupported store payment flows, unreliable references or missing permissions remain limited or unknown. Optional fee information is not added to the order’s payment difference.
How to connect monitoring safely
- Create a restricted Stripe key with the read permissions listed in the dashboard; full secret keys are refused.
- Connect WooCommerce separately and review account attribution and live/test coverage. Additional Stripe permissions are optional where the dashboard says so.
- Confirm source freshness, examine the first order matches and then configure the financial notifications you need.
PayPal cannot provide strictly read-only credentials; Business Watchdog restricts its own requests and explains this before connection. Read the security and access details
Questions worth separating
Can fees explain a capture mismatch?
Fees may explain a smaller settlement, but they do not reduce the amount captured from the buyer for the order.
Does payment_intent.succeeded create another payment?
No. An event describes a payment state; reconcile the underlying charge/capture evidence without counting the event twice.
Related troubleshooting guides
Keep the next discrepancy visible
Connect your store and the supported payment provider. Review the coverage and first synchronization before relying on the results. Features and limits depend on your plan.