At a glance
The count of successful Square payments in the period across all channels (POS, Square Online, Invoices, Virtual Terminal, Tap to Pay). The denominator behind average transaction size; the numerator behind volume-per-day trending. Each/v2/paymentsrow withstatus = COMPLETEDis one transaction, regardless of value.
| What it counts | COUNT(/v2/payments WHERE status = COMPLETED). One row per payment, including all source_type values: CARD (POS card-present), EXTERNAL (Square Online + API), CASH (POS cash drawer), CASH_APP (Cash App Pay), WALLET (Apple/Google Pay POS). |
| API endpoint | GET /v2/payments. Paginated 100 per page; the engine walks the cursor for the period. |
| Currency | Currency-neutral (count, not amount). |
| Refunds | NOT subtracted (refunds are events on /v2/refunds, not “uncounted” payments). A refund does not reduce the transaction count. |
| Disputes | NOT subtracted (disputes are post-success and don’t reverse the count). |
| Failed / declined | Excluded. Only COMPLETED rows. APPROVED, PENDING, FAILED, CANCELED are excluded; declines tracked in squ_decline_rate. |
| Cash inclusion | Yes. Cash drawer transactions (source_type = CASH) ARE counted. Some retail merchants are surprised; switch to a card-only filter if needed. |
| Same-day refunds | Original payment still counts. If you sold and refunded a 20 in squ_refund_volume. |
| Order vs payment | One Square Order can have multiple payments (split tender: card + cash). Each payment is one row here. The order count is lower; this card counts payment events. |
| Subscription rebills | Each rebill = one transaction. |
| Time window | 30D vsP (default 30D vs the prior 30D). |
| Alert trigger | drop >15% vsP, paired with revenue_trend. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Square data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The same Austin bookshop (“Ravenwing Books”) on 30-day window 03 Apr 26 to 02 May 26.| Channel | Count | Avg ticket | source_type |
|---|---|---|---|
| Front-counter POS chip + tap | 3,420 | USD 22.92 | CARD |
| Cash drawer | 1,180 | USD 12.03 | CASH |
| Square Online | 612 | USD 34.80 | EXTERNAL |
| Cash App Pay (online) | 88 | USD 33.41 | CASH_APP |
| Apple Pay / Google Pay (POS) | 240 | USD 21.67 | WALLET |
| Square Invoices | 14 | USD 342.86 | EXTERNAL |
| Tap to Pay on iPhone (Saturday market) | 95 | USD 22.95 | CARD |
- POS dominates count, not value. 4,935 of 5,649 transactions (87.4%) are POS; only 714 are online. But online’s average ticket (USD 34.80) is materially higher than POS retail (USD 22.92), so the value split is more balanced than the count split.
- Cash transactions skew the average down. Cash-drawer transactions (USD 12.03 avg) are mostly small-value impulse buys (a single magazine, a coffee). They pull the blended average ticket down. Some merchants exclude cash from the avg-ticket card; this card always counts them.
- Square Invoices have a wildly higher average. 14 invoices at USD 342.86 average is the trade / event channel (book signings, schools, libraries). It’s a small count but materially affects the per-channel revenue mix.
- Tap to Pay on iPhone count = 95. A small but meaningful number for a Saturday-morning pop-up; this is volume that simply did not exist before 2023 for sole proprietors. No hardware was bought; the owner used their own iPhone.
- Day-of-week seasonality. Splitting these 5,649 transactions by day, Saturday peaks at ~310 transactions, Sunday at ~210, weekdays at ~150, 180. Retail-led Square merchants always see this shape; ecom-led merchants typically see a Tue/Wed/Thu peak.
Sibling cards merchants should reference together
| Card | Why pair with Total Transactions |
|---|---|
squ_total_volume | Volume ÷ transactions = average ticket. |
squ_avg_transaction | The per-transaction view. |
squ_volume_trend | Daily transaction count is the cleanest seasonality signal. |
squ_top_payment_methods | Tender mix breakdown. Tap > chip > magstripe in 2026 US POS. |
squ_success_rate | Successful ÷ attempted ratio. Pair with this card to read attempts vs successes. |
squ_decline_rate | The complement, reads in the same denominator (attempts). |
Stripe stripe_transaction_count / Viva viva_total_transactions | Cross-PSP comparison for merchants running multiple processors. |
Shopify / BC total_orders | Commerce-platform order count; Square’s online subset should reconcile. |
Reconciling against the vendor’s own dashboard
Where to look in the Square Dashboard: Sign in at squareup.com/dashboard. The closest comparable view is:Reports → Sales → Sales Summary (filter by date range; “Transactions” tile)Other views:
- Reports → Transactions (per-transaction list). This is the underlying ledger this card counts.
- Reports → Sales by source (POS / Online / API / Invoices breakdown). Useful for splitting the count.
- Items → Item sales (per-SKU). Higher than transaction count because one transaction often has multiple line items.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Square Dashboard uses the location’s timezone (Austin = America/Chicago). Vortex IQ uses UTC. For “today” cards a Texas merchant sees a 5, 6 hour shift. |
| Tender filter | Ours often higher | Dashboard tile sometimes defaults to “Card transactions”; this card sums all tender. Switch the tile to “All transactions” to match. |
| Refund flag | Same direction | Some Dashboard tiles deduct fully-refunded transactions from the count; this card does not. |
| Refresh lag | Ours lower for “today” | Periodic sync; freshest 5, 15 minutes may be missing. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
squ_total_transactions ↔ commerce total_orders | square ≤ commerce + buffer | An ecom store with Square as gateway should have square_online_count ≈ commerce_order_count, less manual / draft / cancelled orders. |
squ_total_transactions ↔ POS-only count | POS = total - online subset | Useful for retail-only seasonality without ecom contamination. |
Known limitations / merchant FAQs
“Does this count POS and online together?” Yes, it’s the unified/v2/payments count. POS card-present, Square Online checkouts, Cash App Pay, Apple Pay, cash drawer, Tap to Pay, and Invoices all flow through the same ledger. This is Square’s core product positioning and the single most useful operational property of the API.
“My split-tender transactions, how do those count?”
Square Orders can be paid by multiple payments (e.g. a USD 100 order paid USD 60 by card + USD 40 by cash). That’s two /v2/payments rows = two transactions in this card. The order count is one. If you want order count specifically, the /v2/orders endpoint is the right source; this card uses payments deliberately for revenue parity.
“Do failed taps that the customer re-tapped count once or multiple times?”
Once. A failed authorisation creates a FAILED row; that’s excluded. The successful re-tap creates a separate COMPLETED row; that’s the one counted. So a tap-fail-then-tap-succeed pattern produces one count, not two.
“What about Square’s offline mode (no internet at the till)?”
Square POS stores offline transactions locally and uploads when connectivity returns. They appear in /v2/payments with the original transaction time once uploaded. If a sync window misses the upload, the count for that period stays low until the catch-up sync.
“Subscription rebills and recurring invoices, how do those count?”
Each rebill or auto-charged invoice is one transaction here. Square Subscriptions creates a /v2/payments row on each successful rebill.
“Why is the transaction count higher than my order count in Square?”
Split-tender (one order, multiple payments) is the most common cause. Tipping (a tip applied after the original sale via /v2/payments/{id}/complete) is sometimes a separate event. Re-runs after a chip-read failure that succeeded second time aren’t double-counted (the failed attempt was excluded).
“My pop-up market sales on Tap to Pay on iPhone, do those count?”
Yes, indistinguishably from chip-and-tap on a Square Reader. source_type = CARD, entry_method = CONTACTLESS. The only difference is device_details is absent (no hardware terminal ID).
“Multi-currency, does this work?”
Yes; this card is a pure count, currency-neutral. A merchant with one US location (USD) and one Canadian location (CAD) gets a single combined transaction count.