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.
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:
- 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 card is the unambiguous breakdown; the FX-normalised view is a manifest toggle that finance can request.
- Decision Manager
REVIEWis 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/searchescalls 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. - 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.
- 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.
- PARTIAL_AUTHORIZED excluded (correctly). A
PARTIAL_AUTHORIZEDoutcome 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.
Sibling cards merchants should reference together
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) filtered toStatus = Authorised for the same date range, summed by amount.
Other authoritative views in EBC2:
- Reports → Standard Reports → Conversion Detail Report, 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, 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 for the ACCEPT vs REVIEW vs REJECT split feeding the AUTHORIZED count.
Cross-platform reconciliation, what should match what:
Quick rule for support tickets: if a finance lead says “EBC2 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.
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 + Avg Settlement Time to see what is in flight; the 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 and 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.
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 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 and 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.
/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 card is the proper view; an FX-normalised total can be added as a manifest setting if finance prefers.