> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Total Charge Volume, Stripe

> Total Charge Volume for Stripe stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it.

**Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained)  •  **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type)

## 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 |

```text theme={null}
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):

```text theme={null}
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`](/nerve-centre/kpi-cards/stripe/decline-rate) for payment-side drag; (b) [`stripe_total_charges`](/nerve-centre/kpi-cards/stripe/total-charges) for transaction-count change vs basket-size change; (c) [Shopify `total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) or [BC `total_revenue`](/nerve-centre/kpi-cards/bigcommerce/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`](/nerve-centre/kpi-cards/stripe/average-transaction-value).** 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`](/nerve-centre/stripe/stripe_payout_age_days) and [`stripe_oldest_pending_payout`](/nerve-centre/kpi-cards/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`](/nerve-centre/kpi-cards/stripe/revenue-at-risk).** 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 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`](/nerve-centre/kpi-cards/stripe/net-revenue)                                                                                 | Same metric minus refunds and estimated 2.9%+30¢ fees, closer to a P\&L view                                |
| [`stripe_revenue_by_currency`](/nerve-centre/kpi-cards/stripe/revenue-by-currency)                                                                 | The unambiguous per-currency breakdown when this card sums multiple currencies                              |
| [`stripe_refund_value`](/nerve-centre/kpi-cards/stripe/refund-value)                                                                               | The amount to subtract for a net-of-refunds figure                                                          |
| [`stripe_dispute_value`](/nerve-centre/kpi-cards/stripe/dispute-value)                                                                             | The amount tied up in chargebacks (not deducted here)                                                       |
| [`stripe_avg_transaction`](/nerve-centre/kpi-cards/stripe/average-transaction-value)                                                               | The denominator-aware view (`total ÷ successful_charges`)                                                   |
| [`stripe_revenue_trend`](/nerve-centre/kpi-cards/stripe/revenue-over-time)                                                                         | Same metric trended daily                                                                                   |
| [`stripe_revenue_by_country`](/nerve-centre/kpi-cards/stripe/revenue-by-country)                                                                   | Geographic breakdown using billing-country (fallback card-country)                                          |
| Shopify [`total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) / BC [`total_revenue`](/nerve-centre/kpi-cards/bigcommerce/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](https://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`](/nerve-centre/kpi-cards/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`](/nerve-centre/kpi-cards/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`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | `stripe ≤ adobe_commerce`  | Same logic. Adobe Commerce stores frequently use Cybersource, Braintree, Worldpay                                                           |
| `stripe_total_revenue` + [`paypal.pp_total_volume`](/nerve-centre/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`](/nerve-centre/kpi-cards/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`](/nerve-centre/kpi-cards/stripe/revenue-over-time) 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`](/nerve-centre/kpi-cards/stripe/connect-platform-fees-earned) 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.