Total Charge Volume, Stripe

Metrics type: Key Metrics • 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 counts	Every charge on `/v1/charges` where `status = succeeded`, summed by `amount_captured` (or `amount` when capture is immediate).
VAT / tax treatment	Inclusive, 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.
Currency	Multi-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 cost	Gross. Stripe processing fees (~2.9% + 30¢) are NOT deducted. See Net Revenue for the post-fee figure.
Refunds	NOT 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 / chargebacks	NOT deducted. A successful charge that’s later disputed still counts here. See Dispute Value separately.
Failed / declined payments	Excluded, only `status = succeeded` rows are summed. Declined Charges tracks the rest.
Payout timing	Per charge (when the customer paid), NOT per payout (when Stripe transferred to your bank). For settlement timing see Average Settlement Time.
Capture mode	Uses `amount_captured` when set (delayed-capture flows), falling back to `amount` for immediate captures. Authorisations that were never captured don’t count.
Time window	`T/7D/30D vsP` (default 30D vs previous 30D)
Page cap	API-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 trigger	`drop >15% vsP`
Sentiment key	`revenue_trend`
Roles	owner, 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:

Charge	`amount` (cents)	`amount_captured`	`currency`	`status`	Refund	Dispute	Notes
ch_001	12000	12000	gbp	succeeded	-	-	Standard order
ch_002	6000	6000	gbp	succeeded	£60.00 (full)	-	Customer refunded
ch_003	24000	24000	gbp	succeeded	-	£240 lost	Lost chargeback
ch_004	5000	-	gbp	failed	-	-	Card declined
ch_005	8000	8000	eur	succeeded	-	-	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:

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.
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).
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.
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.
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 horizon	Action
First 1 hour after alert	Confirm the alert is real (not a connector refresh artefact). Check Stripe Dashboard for the same period; if Dashboard agrees, escalate.
First 4 hours	Decompose by transaction count vs avg transaction. Identify whether processor-side drag is the cause via decline rate and pending-payout cards.
First 24 hours	Cross-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 week	If 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

Card	Why merchants reach for it
`stripe_net_revenue`	Same metric minus refunds and estimated 2.9%+30¢ fees, closer to a P&L view
`stripe_revenue_by_currency`	The unambiguous per-currency breakdown when this card sums multiple currencies
`stripe_refund_value`	The amount to subtract for a net-of-refunds figure
`stripe_dispute_value`	The amount tied up in chargebacks (not deducted here)
`stripe_avg_transaction`	The denominator-aware view (`total ÷ successful_charges`)
`stripe_revenue_trend`	Same metric trended daily
`stripe_revenue_by_country`	Geographic breakdown using billing-country (fallback card-country)
Shopify `total_revenue` / BC `total_revenue`	The 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:

Reason	Direction	What to do
Page cap, we fetch up to 1,000 charges per refresh; Stripe Dashboard has no cap	Ours lower	Merchants 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 currency	Ours arithmetically wrong as a single number, but accurate per-currency	Use 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 boundaries	Boundary days differ	Largest 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 captured	Ours 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 view	Ours lower for the most recent hour	Wait for next refresh; check `last_synced_at` in the card metadata

Cross-platform reconciliation, what should match what:

Comparison	Expected relationship	When divergence is legitimate
`stripe_total_revenue` ↔ `shopify.total_revenue`	`stripe ≤ shopify`	Shopify 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_revenue`	`stripe ≤ bigcommerce`	Same logic. BC supports many non-Stripe gateways (Braintree, Authorize.net, PayPal, Square, Cybersource); each one displaces Stripe revenue
`stripe_total_revenue` ↔ `adobe_commerce.total_revenue`	`stripe ≤ adobe_commerce`	Same logic. Adobe Commerce stores frequently use Cybersource, Braintree, Worldpay
`stripe_total_revenue` + `paypal.pp_total_volume`	`≈ commerce_total_revenue`	The 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.

Get Started

The AI OS

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre