> ## 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 Transaction Value, CyberSource > Total Transaction Value for CyberSource 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 CyberSource** in the period, gross of refunds, gross of interchange / acquirer fees, gross of disputes. This is "money that touched our enterprise gateway", not "money we kept". Authoritative source for finance teams reconciling daily processing volume to bank settlements; should be the largest payment-volume number on the board pack for any CyberSource-primary merchant. | | | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Every transaction returned from `/tss/v2/searches` where `status = AUTHORIZED`, summed by `totalAmount`. Includes one-time, recurring, tokenized, fresh-card, 3DS-authenticated, and frictionless flows. | | **Decision Manager treatment** | DM `ACCEPT` outcomes that authorise are counted. DM `REVIEW` outcomes are NOT counted here (they sit on `cs_review_rate` until ops manually approves and re-authorises). DM `REJECT` outcomes are not counted (never authorised). | | **3DS handling** | 3DS 2.0 frictionless and successful-challenge transactions are counted (they end in `AUTHORIZED`). Abandoned-challenge transactions are NOT (they never authorised). See [3DS Challenge Abandon Rate](/nerve-centre/kpi-cards/cybersource/3ds-challenge-abandon-rate). | | **Tokenization** | Network-token (Visa VTS / Mastercard MDES) and PAN-token (TMS) transactions both counted. The auth-rate uplift on tokens (typically 4, 8pp on network tokens) is reflected in this number; merchants growing their tokenized book see this card grow disproportionately to fresh-card volume. | | **Recurring vs one-time** | Both counted, no split. Recurring-billing volume from `/reporting/v3/conversion-details` is included if it authorised. For the recurring-only view see [Recurring Charge Volume](/nerve-centre/kpi-cards/cybersource/recurring-charge-volume). | | **Currency** | **Multi-currency without FX.** Each transaction is summed in its presentment `currency`. A USD merchant ID processing USD + EUR + GBP + AUD + JPY will see arithmetic USD + EUR + GBP + AUD + JPY with no conversion. Use [Revenue by Currency](/nerve-centre/kpi-cards/cybersource/revenue-by-currency) for the per-currency breakdown. | | **Fees / processing cost** | **Gross.** CyberSource gateway fees, interchange, acquirer fees, scheme fees, and any rolling reserves are NOT deducted. See [Net Revenue](/nerve-centre/kpi-cards/cybersource/net-revenue) for the post-fee enterprise figure. | | **Refunds** | **NOT deducted.** A fully refunded $100 transaction contributes $100 to this card. See [Refund Value](/nerve-centre/kpi-cards/cybersource/refund-value) and [Net Revenue](/nerve-centre/kpi-cards/cybersource/net-revenue). | | **Disputes / chargebacks** | **NOT deducted.** A successful authorisation later disputed (and lost) still counts here. See [Chargeback Value](/nerve-centre/kpi-cards/cybersource/chargeback-value). | | **Failed / declined payments** | **Excluded.** Only `status = AUTHORIZED` rows are summed. `DECLINED`, `REVIEW`, `INVALID_REQUEST`, `PARTIAL_AUTHORIZED` excluded. | | **Payout timing** | **Per transaction** (when authorised), NOT per settlement batch. For batch / payout timing see [Avg Settlement Time](/nerve-centre/kpi-cards/cybersource/avg-settlement-time) and [Pending Settlement](/nerve-centre/kpi-cards/cybersource/pending-settlement). | | **Time window** | `T / 7D / 30D vsP` (default 30D vs prior 30D). | | **Page cap** | `/tss/v2/searches` API has an offset-paginated 2,000-record limit per request. At enterprise volume (50k+ tx/day) the engine pages through; full-day pulls with refresh windows >24h can take 30, 90 seconds. Reporting v3 (overnight batch) is the authoritative source for historical reconciliation. | | **Reporting API extraction lag** | Real-time via `/tss/v2/searches` for the most recent 7 days. Historical periods (>7 days) pull from `/reporting/v3/conversion-details` which runs an overnight batch; expect 2, 6 hours of staleness on the most recent day for the historical view. | | **Alert trigger** | `drop > 15% vsP`. Calibrated for enterprise stability (most enterprise merchants don't move 15% week-over-week organically; a 15% drop indicates an incident). | | **Sentiment key** | `revenue_trend` | | **Roles** | owner, finance, operations | ## Calculation Calculated automatically from your CyberSource 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 multi-property hotel group running CyberSource for room-charge and folio billing across North America and Europe. The 30-day window covers 14 Mar 26 to 12 Apr 26. The group processes \~62,000 transactions per day across all properties. The transaction mix from `/tss/v2/searches`: | Status | Count | Sum (USD-equiv) | Notes | | -------------------- | --------- | --------------- | --------------------------------------------------------------------------- | | `AUTHORIZED` (USD) | 1,420,500 | \$312.4M | Domestic USD bookings | | `AUTHORIZED` (EUR) | 248,700 | €68.2M | EU property bookings, presented in EUR | | `AUTHORIZED` (GBP) | 89,400 | £24.8M | UK property bookings | | `AUTHORIZED` (CAD) | 41,200 | C\$11.6M | Canadian property bookings | | `DECLINED` | 142,800 | n/a | Excluded | | `REVIEW` | 38,100 | n/a | Excluded (Decision Manager queue) | | `PARTIAL_AUTHORIZED` | 6,200 | \$1.4M | Excluded (gift-card-plus-credit-card splits where the credit card declined) | | `INVALID_REQUEST` | 1,890 | n/a | Excluded | ```text theme={null} Total Transaction Value (this card) = $312.4M + €68.2M + £24.8M + C$11.6M (no FX conversion, summed in presentment currency) ``` What the merchant might *expect* (and which other cards to use): ```text theme={null} Net Revenue (after refunds + fees) ≈ $312.4M − $4.2M refunds − ~$8.7M fees ≈ $299.5M (USD only) Total kept after disputes lost ≈ $299.5M − $1.1M lost disputes ≈ $298.4M USD-normalised view (FX at period close) ≈ $312.4M + $74.3M + $30.9M + $8.6M ≈ $426.2M ``` Five things worth noticing for an enterprise hotel finance lead: 1. **Multi-currency arithmetic is a frequent surprise.** Finance teams expect a single USD-equivalent figure on the board pack, but the engine sums each currency in its own units to preserve the audit trail. The [Revenue by Currency](/nerve-centre/kpi-cards/cybersource/revenue-by-currency) card is the unambiguous breakdown; the FX-normalised view is a manifest toggle that finance can request. 2. **Decision Manager `REVIEW` is excluded by design.** 38,100 transactions sat in DM REVIEW for this period. Of those, ops manually approved \~31,400 within 4 hours (the operating SLA), which then re-submitted as fresh `/tss/v2/searches` calls and authorised. Those re-authorisation transactions ARE in the AUTHORIZED count. The 6,700 that ops never approved (or that customers abandoned during review) are correctly excluded. 3. **Tokenization carrying the auth rate.** 78% of this hotel group's transactions came from CyberSource Token Management Service (corporate-account billing, repeat guest profiles, OTA partner integrations). TMS-tokenized auth rate ran 96.8% vs fresh-card 91.2%. The blended \~94.4% reflects the heavy TMS skew; if the merchant suddenly took more direct-fresh-card traffic (e.g. switched OTAs), this card's growth rate would slow even with stable booking volume. 4. **Cross-border share matters for the dispute-rate denominator.** 23% of authorised volume was cross-border (card-issuing-country ≠ merchant-billing-country). Cross-border transactions have higher chargeback rates (typically 1.5, 2x the domestic rate) so the dispute denominator built off this card carries more risk per dollar than a pure-domestic merchant would. See [Cross-Border Transaction Share](/nerve-centre/kpi-cards/cybersource/cross-border-transaction-share). 5. **PARTIAL\_AUTHORIZED excluded (correctly).** A `PARTIAL_AUTHORIZED` outcome means the issuer authorised a smaller amount than requested (typical on prepaid cards near balance limit, or on travel-booking gift-card splits). The hotel ops team typically captures the partial amount and seeks alternate tender for the balance; that re-submission flows through as a separate AUTHORIZED. Counting partial-auth here would double-count revenue. EBC2 surfaces partial-auth in its own bucket. If the next 30-day period dropped 18% vs prior (>15% threshold), the alert fires. The first three places to look are [Top Decline Reasons](/nerve-centre/kpi-cards/cybersource/top-decline-reasons) (was there a Decision Manager rule misfire?), [Decline Rate by Card-Country](/nerve-centre/kpi-cards/cybersource/decline-rate-by-card-country) (did a specific issuer-country book fall off?), and [Cross-Border Transaction Share](/nerve-centre/kpi-cards/cybersource/cross-border-transaction-share) (did international booking volume drop, common when EUR/USD FX moves >5% in a period). ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Net Revenue (after refunds + fees)](/nerve-centre/kpi-cards/cybersource/net-revenue) | Same metric minus refunds, gateway fees, interchange, and acquirer fees. The closer-to-P\&L view. | | [Revenue by Currency](/nerve-centre/kpi-cards/cybersource/revenue-by-currency) | The unambiguous per-currency breakdown when this card sums multiple currencies. Required for finance teams reconciling against bank settlements per-currency. | | [Refund Value](/nerve-centre/kpi-cards/cybersource/refund-value) | The amount to subtract for a net-of-refunds figure. | | [Chargeback Value (30d)](/nerve-centre/kpi-cards/cybersource/chargeback-value) | The amount tied up in chargebacks (not deducted here). | | [Average Transaction Value](/nerve-centre/kpi-cards/cybersource/average-transaction-value) | Denominator-aware view (`total ÷ AUTHORIZED count`). Useful for spotting basket-size drift. | | [Revenue Over Time](/nerve-centre/kpi-cards/cybersource/revenue-over-time) | Same metric trended daily. | | [Revenue by Country](/nerve-centre/kpi-cards/cybersource/revenue-by-country) | Geographic breakdown using `billingCountry` (fallback `cardCountry`). | | [Stripe Total Charge Volume](/nerve-centre/kpi-cards/stripe/total-charge-volume) | Cross-processor peer for multi-acquirer enterprises. CyberSource volume + Stripe volume should approach the commerce platform's total revenue minus other gateway revenue. | | Adobe Commerce / BigCommerce / Shopify [`total_revenue`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | Upstream commerce view. CyberSource should reconcile to (commerce\_total − non-CS-payment-method orders). For enterprise merchants on Adobe Commerce, CS is often the primary gateway so the two numbers track closely. | ## Reconciling against the vendor's own dashboard **Where to look in CyberSource Business Center (EBC2):** The closest comparable is **EBC2 → Transactions → Search** ([ebc2.cybersource.com/ebc2/app/Transactions/transactions](https://ebc2.cybersource.com/ebc2/app/Transactions/transactions)) filtered to `Status = Authorised` for the same date range, summed by amount. Other authoritative views in EBC2: * [Reports → Standard Reports → Conversion Detail Report](https://ebc2.cybersource.com/ebc2/app/Reports/StandardReports), the daily transaction-level dump for finance reconciliation. This is the source of truth for "what did our gateway authorise yesterday". * [Reports → Payment Batch Detail Report](https://ebc2.cybersource.com/ebc2/app/Reports/StandardReports), the settlement-batch view (what arrived at the acquirer's bank account). This will be **lower** than this card by gateway fees, interchange, and any held / disputed transactions. * [Decisions → Decision Manager → Performance Reports](https://ebc2.cybersource.com/ebc2/app/RiskManagement/DecisionManager) for the ACCEPT vs REVIEW vs REJECT split feeding the AUTHORIZED count. **Why our number may legitimately differ from EBC2:** | Reason | Direction | What to do | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Reporting API extraction lag**. For windows >7 days back we use Reporting v3 (overnight batch). EBC2 transaction search is real-time. | Vortex IQ may lag EBC2 by 2-6 hours on the most recent day. | Compare equal date ranges using `submitTimeUtc`, not local-day boundaries. | | **Time zone**. EBC2 uses the merchant-account-configured time zone; we use UTC. | Boundary-day **drift**. | Largest impact on "today" / "yesterday"; 7D / 30D averages out. | | **Multi-currency presentation**. EBC2 by default surfaces a USD-equivalent column at fixed FX; we sum each currency in its own units. | Ours **arithmetically wrong as a single number, but accurate per-currency**. | Use [Revenue by Currency](/nerve-centre/kpi-cards/cybersource/revenue-by-currency), or request the FX-normalised view. | | **Page cap**. `/tss/v2/searches` returns up to 2,000 records per page; our engine pages through up to a configured ceiling. EBC2 has no equivalent cap on its UI views. | Ours **lower** if the daily volume cap is hit. | Enterprise merchants doing >100k tx/day should rely on Reporting v3 (overnight) for full-day reconciliation. | | **`PARTIAL_AUTHORIZED` treatment**. We exclude (the customer's primary card was declined for the requested amount). EBC2 surfaces them in their own bucket; finance teams sometimes accidentally include them. | Ours **lower**. | This is intentional; partial-auth re-submissions flow through as separate AUTHORIZED rows. | | **Refresh lag**. Last refresh may be 5, 15 minutes behind real-time. | Ours **lower** for the most recent hour. | Wait for next refresh; check `last_synced_at` in card metadata. | **Cross-platform reconciliation, what should match what:** | Comparison | Expected relationship | When divergence is legitimate | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `cs_total_revenue` ↔ [`adobe_commerce.total_revenue`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | `cs ≤ adobe_commerce` | Adobe Commerce includes orders paid via PayPal, Apple Pay direct, Klarna, gift cards, and any non-CS gateway. For enterprise merchants on AC where CS is the primary gateway, CS often runs 75, 92% of AC total revenue. | | `cs_total_revenue` ↔ [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | `cs ≤ bigcommerce` | Same logic. Mid-market BC stores using CS as enterprise gateway typically run lower CS share (40, 70%) because BC stores often blend Stripe / Braintree / PayPal alongside CS. | | `cs_total_revenue` + [`stripe.stripe_total_revenue`](/nerve-centre/kpi-cards/stripe/total-charge-volume) + [`paypal.pp_total_volume`](/nerve-centre/paypal/pp_total_volume) | `≈ commerce_total_revenue` | The three payment volumes summed (in matching currency) should approach the commerce platform's total minus gift-card / store-credit / non-card volume. | | `cs_total_revenue` ↔ EBC2 Payment Batch Detail (settlement) | `cs ≥ batch settlement` | Gateway fees, interchange, scheme fees, and held / pending settlement transactions all shrink the batch figure. The gap is usually 2.5, 4.0% (typical CS-fee + interchange band). | **Quick rule for support tickets:** if a finance lead says *"EBC2 shows $312M, your dashboard shows $295M for the same period"*, walk through the reconciliation table. The `PARTIAL_AUTHORIZED` exclusion and the multi-currency presentation are the two most common causes for enterprise finance teams; refresh lag is the most common for "today" complaints. ***
Documentation cross-reference (for multi-acquirer enterprise merchants) The Stripe peer is [`stripe.stripe_total_revenue`](/nerve-centre/kpi-cards/stripe/total-charge-volume). The same gross-of-fees-and-refunds rule applies. Multi-acquirer enterprises (large airlines, marketplaces, OTAs) often run CS as the primary high-AOV gateway and Stripe as the SMB / mobile / one-touch fallback; sum both for the full processing-volume picture.
## Known limitations / merchant FAQs > Reconciliation questions ("why doesn't this match EBC2 / 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 our acquirer's bank account?** Total Transaction Value is **gross of CyberSource gateway fees, interchange, acquirer fees, scheme fees, refunds, and disputes**. The bank-side settlement figure reflects net-of-all-of-that. Use [Pending Settlement](/nerve-centre/kpi-cards/cybersource/pending-settlement) + [Avg Settlement Time](/nerve-centre/kpi-cards/cybersource/avg-settlement-time) to see what is in flight; the [Net Revenue](/nerve-centre/kpi-cards/cybersource/net-revenue) card shows the post-deduction figure. **Why don't I see PayPal-routed transactions in CyberSource Total Revenue?** PayPal payments don't flow through CyberSource (they go to PayPal's own settlement). For multi-gateway enterprise merchants the right total is `cs_total_revenue + stripe_total_revenue + pp_total_volume + ...`. See the cross-platform reconciliation table above. **Are 3DS-failed transactions counted?** No. 3DS-failed transactions end with `status = DECLINED` (the issuer declined the auth following the failed authentication) and are excluded. They appear in [Declined Transactions](/nerve-centre/kpi-cards/cybersource/declined-transactions) and [3DS Challenge Abandon Rate](/nerve-centre/kpi-cards/cybersource/3ds-challenge-abandon-rate). **Are Decision Manager `REVIEW` transactions counted?** No, not directly. A transaction that DM flagged for REVIEW is held until ops manually approves and the merchant re-submits the auth (which then comes back as a separate `/payments` call). If that re-auth succeeds, the AUTHORIZED row is in this card. If the customer abandoned during review or ops rejected, nothing is counted. See [Under-Review Rate](/nerve-centre/kpi-cards/cybersource/under-review-rate). **What about `PARTIAL_AUTHORIZED`?** Excluded. Partial auths happen when the issuer authorises a smaller amount than requested (typical on prepaid cards near balance limit). Most ops flows handle this by capturing the partial and seeking alternate tender for the balance; that re-submission flows as a separate AUTHORIZED. **Why are some enterprise merchants seeing weekly drops without an obvious cause?** Three structural reasons unique to enterprise CyberSource books: * **Quarterly Decision Manager rule pack rollouts.** Fraud-ops teams typically deploy DM rule changes on a quarterly cadence; a too-aggressive rule can cut authorisations 5, 12% within a single quarter. Check [Decision Manager Score Mix](/nerve-centre/kpi-cards/cybersource/decision-manager-score-mix) before assuming traffic loss. * **Cross-border FX shifts.** EUR/USD or GBP/USD moving >5% within a period changes both demand (consumer side) and authorisation rates (issuer-side credit-line tightening on weakening currencies). Watch [Revenue by Country](/nerve-centre/kpi-cards/cybersource/revenue-by-country) and [Decline Rate by Card-Country](/nerve-centre/kpi-cards/cybersource/decline-rate-by-card-country). * **Token Management Service expiration cliffs.** When a large cohort of stored tokens expires simultaneously (e.g. all the cards stored during a Q4 holiday push expire 12 months later), the recurring-billing book sees a temporary auth-rate dip. See [Stored-Token Health](/nerve-centre/kpi-cards/cybersource/stored-token-health). **Does this card include MOTO (Mail Order / Telephone Order) transactions?** Yes, if they authorised. CyberSource processes both card-not-present-online and MOTO through the same `/payments` endpoint; both end in AUTHORIZED if the issuer approves. The split lives elsewhere (typically `applicationName` or sub-merchant tag), not in this card. **Does this card include card-present (POS) transactions?** Most enterprise CyberSource integrations are e-commerce / MOTO only, but some merchants run unified card-present + e-commerce gateways. If yes, both contribute. CP transactions usually run materially higher auth rates (98, 99%) so a heavy CP merchant will see this card grow at a different cadence than a pure-CNP enterprise. **Why do I see two currencies summed instead of one normalised total?** Multi-currency arithmetic without FX is intentional. Finance teams reconciling against bank settlements need the per-currency figure; FX-normalised figures introduce reconciliation drift because the FX rate at "now" doesn't match the FX rate at "transaction time" or "settlement time". The [Revenue by Currency](/nerve-centre/kpi-cards/cybersource/revenue-by-currency) card is the proper view; an FX-normalised total can be added as a manifest setting if finance prefers. *** ### Tracked live in Vortex IQ Nerve Centre *Total Transaction Value* is one of hundreds of KPI pulses Vortex IQ tracks across CyberSource 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.