At a glance
The total count of successful transactions that flowed through Authorize.Net in the period. The volume-card’s denominator. Tells the merchant how busy the gateway has been, separate from how much value moved.
| What it counts | COUNT(transactions) where transactionStatus = settledSuccessfully and transactionType IN (authCaptureTransaction, captureOnlyTransaction). Refunds, voids, declined attempts, and FDS-held rows are excluded. |
| API endpoint | getTransactionListRequest on the Transaction Reporting API. |
| Currency | Currency-neutral (count, not amount). USD or non-USD, every settled transaction is one count. |
| Refunds | Excluded. Counted in aut_refund_volume. |
| Disputes / chargebacks | Excluded from this count (the original sale stays counted; the chargeback itself is a separate event). |
| Failed / declined payments | Excluded. Tracked in aut_decline_rate. |
| Voided pre-settlement | Excluded. A capture that the merchant voided before the nightly batch close does not count. |
| 3DS-passed vs 3DS-frictionless | Both count. 3DS-failed (declined) does not. |
| Recurring ARB rebills | Counted. Each ARB rebill is one transaction. |
| CIM tokenised re-bills (B2B) | Counted. |
| eCheck.Net (ACH) | Counted as transactions same as card. |
| Channel split | Not natively reported by Authorize.Net; web, MOTO, B2B portal, ARB are indistinguishable in the count without merchant-side description or invoiceNumber tagging. |
| Time window | 30D vsP. |
| Alert trigger | drop >15% vsP, driven by sentiment_key: revenue_trend. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Authorize.net data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
“Heartland Hardware Co.” (the same Ohio industrial supply distributor fromaut_total_volume). Window 03 Apr 26 to 02 May 26.
| Channel | Settled count | Notes |
|---|---|---|
| Web checkout (Accept.js) | 1,840 | B2B + B2C mix |
| B2B reorder portal (CIM) | 620 | Repeat customers, average 8 orders/customer/month |
| ARB recurring (maintenance contracts) | 184 | 184 active subscriptions rebilling monthly |
| Telephone orders (AIM keyed-in) | 320 | Sales-rep MOTO |
| Refunds (separate type) | 42 | Excluded |
| Declined attempts | 198 | Excluded |
| Voided pre-settlement | 28 | Excluded |
| FDS-held (pending review) | 14 | Excluded until released |
- The 184 ARB rebills are deceptive. That is one rebill per subscription per month. A separate “active subscription count” is what the CFO actually wants for revenue forecasting; this card cannot answer it directly. The 184 is the rebill event count, not the subscription population.
- B2B reorder portal at 620 transactions on USD 1.14M of volume implies USD 1,840 average order value. That is the strategic asset; the web channel at USD 224 AOV is volume-noisy, the B2B channel is value-dense.
- Voided pre-settlement count of 28 is normal but watch the trend. A void is the merchant cancelling a captured-but-not-yet-batched transaction, typically because the customer cancelled the order or fraud-review caught it. A spike in voids after a marketing campaign suggests the campaign attracted fraudulent traffic.
- FDS-held 14 is healthy. Authorize.Net’s Fraud Detection Suite holds suspicious transactions for merchant review. 0.5% hold-rate (14 of approximately 3,000 attempts) is the live benchmark; over 2% means FDS rules are too tight, under 0.1% means too loose.
- Declined 198 against 2,964 settled is a 6.3% decline rate. Within the normal range for US card-not-present (typically 4 to 8%). Read it alongside
aut_decline_rate.
Sibling cards merchants should reference together
| Card | Why pair it with Total Transactions |
|---|---|
aut_total_volume | The dollar view; volume divided by transactions = average transaction. |
aut_avg_transaction | Per-transaction lens, exposes mix-shift. |
aut_volume_trend | Time-series of volume; pair with this card for “are we doing more transactions or higher AOV?” |
aut_decline_rate | The complementary count, declined attempts as a share of total attempts. |
aut_top_payment_methods | Which networks (Visa, Mastercard, Amex, Discover) drive the count. |
aut_chargeback_rate | Chargeback count as a share of settled count. |
Stripe stripe_total_transactions / PayPal pp_total_transactions | Same-archetype comparison on competing rails. |
Reconciling against the vendor’s own dashboard
Where to look in the Authorize.Net Dashboard: account.authorize.net. Closest comparable view:Reports → Transaction Statistics → Statistics by Settlement Date, “Transaction Count” columnThe Reports → Settled Transactions view’s row count for the date range should equal this card. Other views to be aware of:
- Unsettled Transactions: authorisations not yet captured. Excluded from this count.
- Held Transactions (FDS): pending merchant review. Excluded.
- Recurring Billing → Subscription Activity: ARB rebill count, a subset of this card.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Pacific Time batch cut-off vs UTC. |
| Settled vs captured-pending | Theirs equal or higher | We optionally include captured-pending-settlement; the Dashboard’s Settled view excludes them. |
| FDS hold release timing | Either | A held transaction approved later flips into the count on the next sync. |
| Refresh lag | Ours lower for “today” | Most recent 5 to 15 minutes may not be in. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
aut_total_transactions ↔ commerce-platform order count | aut <= commerce | Commerce platform includes orders paid via other gateways or offline. |
aut_total_transactions ↔ stripe.stripe_total_transactions | Differ by routing | Different gateways for different traffic. |
Known limitations / merchant FAQs
Why does this number not split web vs MOTO vs B2B vs ARB? Authorize.Net’s API does not natively tag channel; everything isauthCaptureTransaction. To split, the merchant must populate a custom description or invoiceNumber convention at submission time, or rely on the upstream commerce platform’s order metadata. Several merchants use prefix patterns (WEB-, MOTO-, B2B-, ARB-) on invoiceNumber for exactly this reason.
Are voided transactions counted?
No. A void cancels a captured-but-not-yet-batched transaction; the customer was never charged. Excluded.
Do refunds count as transactions in this card?
No. Refunds (refundTransaction) are a different transactionType and are tracked in aut_refund_volume.
An ARB rebill that the customer’s card declined, does that count?
No. It is transactionStatus = declined, excluded from this card and tracked in aut_decline_rate. When ARB Smart Retry recovers the rebill on a subsequent attempt, the recovered transaction settles and counts.
Does eCheck.Net (ACH) count?
Yes. eCheck transactions with paymentMethod = eCheck and transactionStatus = settledSuccessfully count. ACH settlement is slower (3 to 5 business days) so the timing of when an eCheck transaction lands in this card is later than card; see aut_avg_settlement_days.
FDS-held transactions, do they count?
Not until the merchant releases them. A held transaction is in FDSPendingReview status; it neither approves nor declines until merchant action. Once approved it counts on the next sync. Once declined it is excluded.
Is a partial-refund counted as one transaction or as two?
The original sale is one transaction (counted). The partial refund is a separate refundTransaction (not counted here, tracked in refund cards). So one settled sale + one partial refund = one transaction in this card, one refund elsewhere.
Visa ownership of Authorize.Net, does it skew the count toward Visa cards?
No. The gateway processes all card networks (Visa, Mastercard, Amex, Discover, Diners, JCB) identically; Visa ownership does not change routing. The mix is determined by the merchant’s customer base, not the gateway. See aut_top_payment_methods for the network split.