Skip to main content
Card class: Hero • Category: Payment Gateway

​
At a glance

The total amount that successfully flowed through Stripe in the period, gross of refunds, gross of fees, gross of disputes. This is “money that touched our processor”, not “money we kept”.
What it countsEvery charge on /v1/charges where status = succeeded, summed by amount_captured (or amount when capture is immediate).
VAT / tax treatmentInclusive, the figure is whatever the customer was charged. If the merchant uses Stripe Tax, tax is bundled into amount; otherwise tax handling sat upstream (Shopify / BigCommerce / Adobe Commerce) and is already reflected in the charged amount. No tax line is subtracted.
CurrencyMulti-currency without FX. Each charge is summed in its own currency. A GBP store taking GBP + EUR charges will see arithmetic GBP + EUR with no conversion. Use Revenue by Currency for the per-currency breakdown.
Fees / processing costGross. Stripe processing fees (~2.9% + 30¢) are NOT deducted. See Net Revenue for the post-fee figure.
RefundsNOT deducted. A fully refunded £100 charge contributes £100 to this card. See Refund Value for the deduction, or Net Revenue for the netted figure.
Disputes / chargebacksNOT deducted. A successful charge that’s later disputed still counts here. See Dispute Value separately.
Failed / declined paymentsExcluded, only status = succeeded rows are summed. Declined Charges tracks the rest.
Payout timingPer charge (when the customer paid), NOT per payout (when Stripe transferred to your bank). For settlement timing see Average Settlement Time.
Capture modeUses amount_captured when set (delayed-capture flows), falling back to amount for immediate captures. Authorisations that were never captured don’t count.
Time windowT/7D/30D vsP (default 30D vs previous 30D)
Page capAPI-paginated with a 1,000-charge limit per request (10 pages × 100). Merchants doing > 1,000 charges/day will see truncated daily totals, see Known limitations below.
Alert triggerdrop >15% vsP
Sentiment keyrevenue_trend
Rolesowner, finance

​
Calculation

Calculated automatically from your Stripe data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

​
Worked example

A UK merchant has five Stripe charges in the period:
Chargeamount (cents)amount_capturedcurrencystatusRefundDisputeNotes
ch_0011200012000gbpsucceeded--Standard order
ch_00260006000gbpsucceeded£60.00 (full)-Customer refunded
ch_0032400024000gbpsucceeded-£240 lostLost chargeback
ch_0045000-gbpfailed--Card declined
ch_00580008000eursucceeded--German customer in EUR
Stripe API returns sum:
  ch_001  → £120.00
  ch_002  → £60.00       (refund NOT deducted)
  ch_003  → £240.00      (dispute NOT deducted)
  ch_004  → excluded     (status='failed')
  ch_005  → €80.00       (different currency, summed without FX)

Total Charge Volume (this card) = £420.00 + €80.00
What the merchant might expect (and which other cards to use): 
Net Revenue (post-fees, post-refunds)             = £420.00 − £60.00 − ~£14.10 (fees est.)  ≈ £345.90
Total Revenue net-of-refunds (Refund Value card)  = £420.00 − £60.00                        =  £360.00
Successfully kept (post-disputes lost)            = £420.00 − £60.00 − £240.00              =  £120.00
Note: the EUR row is a frequent merchant surprise, they expect a single £-converted figure but see two currencies summed. Revenue by Currency is the unambiguous breakdown. The diagnostic flow when this card flags a >15 percent drop:
  1. Decompose by source of decline. A 15 percent drop is large enough to be a genuine business signal. Walk through (a) stripe_decline_rate for payment-side drag; (b) stripe_total_charges for transaction-count change vs basket-size change; (c) Shopify total_revenue or BC total_revenue for the upstream commerce view to determine whether the drop is processor-specific or a broader sales drop.
  2. Cross-reference with stripe_avg_transaction. If transaction count is steady but volume dropped, basket size has fallen (pricing change, mix shift, discount cycle). If basket size is steady but transaction count fell, traffic or conversion is the issue (look upstream to GA4 sessions or commerce-platform conversion rate).
  3. Check stripe_payout_age_days and stripe_oldest_pending_payout. A processor-side hold (Stripe risk review, account verification gap, suspended capability) reduces successful charge volume even when the customer was charged. The pending-payout card surfaces this distinct from a real revenue drop.
  4. Pair with stripe_revenue_at_risk_live. This forward-looking card combines disputes-in-flight, refund-velocity, and recoverable-decline volume to estimate near-term revenue exposure that the headline number does not yet reflect.
  5. For multi-currency brands, layer the per-currency view. A “drop” can be a single weak currency cohort (Brexit-era GBP brands saw £-cohort softness while EUR cohort grew); the per-currency breakdown clarifies whether the drop is broad or concentrated.
The rapid-response playbook for finance and ops:
Time horizonAction
First 1 hour after alertConfirm the alert is real (not a connector refresh artefact). Check Stripe Dashboard for the same period; if Dashboard agrees, escalate.
First 4 hoursDecompose by transaction count vs avg transaction. Identify whether processor-side drag is the cause via decline rate and pending-payout cards.
First 24 hoursCross-reference upstream commerce platform. If Shopify/BC/Adobe revenue agrees with the Stripe drop, the issue is sales-side; if not, the issue is Stripe-specific (often Radar tightening or a captured-amount anomaly).
First weekIf sustained, brief leadership with the decomposition. The Vortex Mind Daily Revenue Leakage report runs the same decomposition automatically and is the executive-ready version of this analysis.

​
Sibling cards merchants should reference together

CardWhy merchants reach for it
stripe_net_revenueSame metric minus refunds and estimated 2.9%+30¢ fees, closer to a P&L view
stripe_revenue_by_currencyThe unambiguous per-currency breakdown when this card sums multiple currencies
stripe_refund_valueThe amount to subtract for a net-of-refunds figure
stripe_dispute_valueThe amount tied up in chargebacks (not deducted here)
stripe_avg_transactionThe denominator-aware view (total ÷ successful_charges)
stripe_revenue_trendSame metric trended daily
stripe_revenue_by_countryGeographic breakdown using billing-country (fallback card-country)
Shopify total_revenue / BC total_revenueThe upstream commerce view. Stripe should reconcile to (commerce_total − non-Stripe-payment-method orders)

​
Reconciling against the vendor’s own dashboard

Where to look in Stripe’s own dashboard: The closest comparable is Stripe Dashboard → Payments → Overview → Gross Volume (dashboard.stripe.com/payments) for the same date range. That page also exposes “Successful Payments” which equals our stripe_successful_charges card. Why our number may legitimately differ from Stripe’s Dashboard:
ReasonDirectionWhat to do
Page cap, we fetch up to 1,000 charges per refresh; Stripe Dashboard has no capOurs lowerMerchants doing > 1,000 charges/day should treat this card as truncated; the warehouse-backed view (rolling out separately) removes the cap
Multi-currency presentation. Stripe converts to your default settlement currency at the day’s FX rate; we sum each charge in its own currencyOurs arithmetically wrong as a single number, but accurate per-currencyUse the Revenue by Currency card for the unambiguous view, or wait for the FX-normalised version
Time zone. Stripe Dashboard uses your account-level time zone setting; we use UTC for the period boundariesBoundary days differLargest impact on “Today” / “Yesterday” cards; for 7D / 30D the drift averages out
Authorised vs captured. Stripe Dashboard’s “Authorised” view includes uncaptured holds; we only count capturedOurs lower when delayed-capture is heavy (fraud-review flows)Compare against Dashboard’s “Successful” filter, not “Authorised”
Refresh lag, our last refresh may be 5-15 minutes behind Stripe’s real-time viewOurs lower for the most recent hourWait for next refresh; check last_synced_at in the card metadata
Cross-platform reconciliation, what should match what:
ComparisonExpected relationshipWhen divergence is legitimate
stripe_total_revenue ↔ shopify.total_revenuestripe ≤ shopifyShopify includes orders paid via PayPal, Apple Pay direct, Klarna direct, manual bank transfer, and gift cards, none of which touch Stripe
stripe_total_revenue ↔ bigcommerce.total_revenuestripe ≤ bigcommerceSame logic. BC supports many non-Stripe gateways (Braintree, Authorize.net, PayPal, Square, Cybersource); each one displaces Stripe revenue
stripe_total_revenue ↔ adobe_commerce.total_revenuestripe ≤ adobe_commerceSame logic. Adobe Commerce stores frequently use Cybersource, Braintree, Worldpay
stripe_total_revenue + paypal.pp_total_volume≈ commerce_total_revenueThe two payment volumes summed (in matching currency) should approach the commerce platform’s total minus other gateway revenue
Quick rule for support tickets: if a merchant says “Stripe shows £100k, your dashboard shows £80k” in the same period, walk through the table above in order, page cap is the most common cause for high-volume merchants, FX is the most common for multi-currency stores, and refresh lag for “today” complaints.

​
Known limitations / merchant FAQs

Reconciliation questions (“why doesn’t this match Stripe Dashboard / my bank?”) are answered in the Reconciling against the vendor’s own dashboard section above. Below are the merchant questions that aren’t reconciliation.
“Why is this higher than what arrived in my bank?” Total Charge Volume is gross of fees, refunds, and disputes. Bank deposits reflect Net Revenue minus refunds disbursed minus disputes lost. Use Pending Balance + Average Settlement Time to see what’s in flight on its way to settlement. “Are 3DS-failed charges counted?” No. 3DS failures end with status = failed and are excluded from this card. They appear in Declined Charges and 3DS Abandon Rate. “Are SCA-required charges that the customer abandoned counted?” No, those are status = requires_action or status = canceled, neither of which is succeeded. They show up in Decline Reasons with reason requires_action_abandoned. “What about delayed-capture authorisations that are still open?” Excluded, they’re status = pending (not succeeded). When you eventually capture, the amount_captured populates and the charge starts contributing. “How do I get a VAT-exclusive view?” (UK-only. US stores have no VAT) There isn’t one on Stripe’s side because Stripe doesn’t know which currency tax inclusion applies. The upstream commerce platform (Shopify / BigCommerce / Adobe) has the tax-inclusive vs tax-exclusive distinction. For UK-store reconciliation, divide by (1 + VAT_rate), typically ÷ 1.20 for 20% VAT, as a rough estimate, or use the upstream commerce card’s ex-VAT view (when added). “Why are some charges missing?” Two cases:
  • The charge was outside the period window (created is the test).
  • The charge has status = pending because of bank-debit / SEPA / 3-day-clearing rails. Once it transitions to succeeded it’ll appear on the next refresh.
“Should I report Total Charge Volume or Net Revenue to the board?” Net Revenue is the more honest figure for board reporting because it reflects what the brand actually keeps after fees and refunds. Total Charge Volume is useful for processor-volume reporting (volume-banding for fee tier negotiations, processor-relationship sizing) but overstates what the business is keeping. The pragmatic split: report Total Charge Volume in the operations review (it is the direct output of the sales engine), report Net Revenue in the board pack (it is the direct input to runway and profitability). The two together tell the full story; either alone tells half of it. The stripe_net_revenue card sits next to this one in the Executive Command Centre for exactly this reason. “How does this card behave during the Black Friday / Cyber Monday spike?” Cleanly, but with a refresh-lag implication merchants should know about. During peak hours (typically the first 4 hours of BFCM Friday and the last 8 hours of Cyber Monday) charge volume can be 50-100x normal. The connector’s refresh cadence remains every 6 hours but the per-refresh charge count can hit the 1,000-charge page cap for high-volume merchants. Brands processing more than 1,000 charges per 6-hour window during peak should expect the headline figure to lag; the trend cards (which use a longer-window aggregation) remain accurate. The warehouse-backed view (rolling out separately) removes the cap and is the recommended source for BFCM real-time monitoring. For brands without warehouse access, cross-check the headline against stripe_revenue_trend which uses a different aggregation path. “Does this card include Stripe Connect platform fees collected from connected accounts?” Depends on the merchant’s Connect configuration. Standard Connect: each connected account has its own Stripe account and its own charge stream; this card on the platform account shows only direct charges, not connected-account charges. Custom or Express Connect: the platform owns the charges; this card includes the gross volume across all connected accounts plus the platform-level direct charges. The stripe_connect_platform_fees card surfaces the platform-fee component separately for Connect-using merchants who want to see “revenue I keep as platform fees” vs “revenue passed to connected merchants”.

​
Tracked live in Vortex IQ Nerve Centre

Total Charge Volume is one of hundreds of KPI pulses Vortex IQ tracks across Stripe and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.