Skip to main content
Card class: Non-HeroCategory: Payment Gateway

At a glance

The count of successful payment captures through Viva Payments in the period. Online Smart Checkout sessions, Smart POS card-present captures, recurring rebills, and pay-by-link are all counted as one each. The denominator that pairs with revenue to triangulate growth shape.
What it countsCOUNT(transactions WHERE StatusId = F) across the Smart Checkout + POS + Recurring API feeds. One row per successful capture.
API endpointGET /api/transactions with status filter.
CurrencyCurrency-neutral (count, not amount). One transaction is one transaction whether it’s EUR 5 or EUR 5,000.
RefundsNOT deducted as a count. A refunded transaction stays counted here; the refund itself is a separate row in viva_refund_value, not this card.
Disputes / chargebacksNOT deducted. A disputed (and even lost-dispute) transaction still counts here.
Failed / declined paymentsExcluded. Only StatusId = F rows count. Failed (E), cancelled (X), max-attempts (M) are tracked in viva_decline_rate.
3DS 2 treatmentFrictionless and successfully-challenged both count. Abandoned challenges (StatusId = X) excluded.
ChannelsOnline + POS + Recurring + Pay-by-link unified. POS volume is typically the largest contributor for omnichannel Mediterranean retailers.
Recurring rebillsEach rebill is one transaction. A subscription customer paying monthly contributes 12 transactions over 12 months, not one.
Payout timingPer transaction date. A transaction late in the period that settles next month still counts here on the date the customer paid.
Time window30D vsP.
Alert triggerdrop >15% vsP.
Rolesowner, finance, operations

Calculation

Calculated automatically from your Viva Payments 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-country Mediterranean marketplace (“Olympia Marketplace”) splits payouts across 40 sub-merchants, runs 8 Smart POS terminals across Athens and Cyprus, and serves a pan-EU e-shop. The 30-day window covers 03 Apr 26 to 02 May 26.
ChannelSuccessful TransactionsNotes
Online Smart Checkout9,840Pan-EU e-shop, 3DS 2 frictionless 76%
Smart POS, Athens flagship4,1206 terminals
Smart POS, Cyprus1,6802 terminals
Recurring rebills2,150Monthly box subscription
Pay-by-link (B2B invoicing)240Sent via SMS / email
Marketplace splitsembeddedEach parent transaction is one row regardless of split count
Successful Transactions (this card):
  Online        +  9,840
  POS           +  5,800
  Recurring     +  2,150
  Pay-by-link   +    240
  Total         = 18,030
Excluded (visible in other cards):
Failed   (E)    =    642   →  viva_decline_rate
Cancelled (X)   =    287   →  viv_threedsecure_abandon_rate (largely 3DS abandons)
Max-attempts (M)=     38   →  viv_decline_rate
What the merchant should notice:
  1. Marketplace split count is hidden. A EUR 200 transaction split between three sub-merchants counts as one row on this card, not three. The split rows live in the dedicated marketplace API and are not exposed here. Merchants benchmarking sub-merchant volume should use the Splits dashboard.
  2. POS makes up 32% of transaction count. Card-present captures are typically the largest contributor to transaction count for omnichannel Mediterranean retailers; their lower average drags blended revenue per transaction down (see viva_avg_transaction) but lifts the count meaningfully. Online merchants often forget POS captures land in the same KPI.
  3. Recurring rebill count grows linearly with subscription base. A 2,150 rebill count this month means roughly 2,150 active monthly subscribers (allowing for some weekly billing). If the next-month figure jumps to 2,500 with no new acquisition, you’re seeing carry-over of failed-then-recovered rebills (Viva auto-retry), tracked separately as recovery on the roadmap.
  4. 3DS abandons at 287 are 1.6% of total successful. Healthy. A figure above 3% suggests 3DS challenge UX needs tuning (the bank pop-up timeout is too short, or the challenge text is in the wrong language for the customer).

Sibling cards merchants should reference together

CardWhy pair it with Successful Transactions
viva_total_revenueThe numerator. Revenue ÷ Transactions = Avg Transaction.
viva_avg_transactionThe per-transaction view. Use both together to read growth shape.
viva_decline_rateThe denominator-of-attempts view. Successful ÷ (Successful + Failed) = success rate.
viv_success_rateThe pass-through rate from attempts.
viva_revenue_trendTime-series. Pair with viv_volume_trend for the count time-series.
viv_total_transactionsSister card (alternate viv_* slug). Same metric, different alert thresholds.
Stripe stripe_total_transactions / PayPal pp_total_transactionsCross-PSP comparison for multi-processor merchants.
Commerce platform shopify.order_countUpstream order count. Viva transactions ≤ Shopify orders for merchants accepting non-Viva methods.

Reconciling against the vendor’s own dashboard

Where to look in the Viva Payments Dashboard: Sign in at viva.com/business/account/login. The closest comparable view is:
Viva Business → Sales → Transactions (filter “Status: Successful”, same date range)
The headline transaction-count tile on Sales overview also matches. Other Viva views that look similar but answer different questions:
  • Settlements view: counts settled batches (one batch per terminal per day), not customer transactions.
  • Disputes view: counts dispute cases, not transactions.
  • Marketplace Splits view: counts splits per parent transaction (so one parent with three splits shows as four rows there, one row here).
Why our number may legitimately differ from the Viva Dashboard:
ReasonDirectionWhy
Time zoneBoundary days offViva Dashboard is account-timezone (Athens EET / EEST for Greek merchants); we use UTC. 3-hour offset can move “today” / “yesterday” cards.
3DS late completionOurs slightly lower for “today”A challenge completed hours later flips pending to F retroactively in their Dashboard; ours updates on next sync.
Page-cap / paginationOurs lower for very high-volume merchantsAPI caps at 100/page; sync interruptions defer the most recent transactions to the next refresh. Stable on 24h+ windows.
Refresh lagOurs lower for last 5, 15 minVortex IQ syncs periodically; the freshest transactions land on the next refresh.
Cross-connector reconciliation:
ComparisonExpected relationshipWhen divergence is legitimate
viva_total_transactionsshopify.order_countviva ≤ shopifyShopify orders paid via Stripe / PayPal / Klarna / gift cards do not touch Viva. For Mediterranean Shopify stores using Viva primary, expect Viva to cover 70, 95% of order count.
viva_total_transactionsbigcommerce.total_ordersviva ≤ bigcommerceSame logic.
viva_total_transactions ↔ Viva Recurring rebillsRecurring is a subsetRecurring rebills are a subset of this count; track separately.

Known limitations / merchant FAQs

Why does Viva show me a different transaction count? The most common cause is the timezone offset, Viva Dashboard renders Athens / Cyprus EET (UTC+2 / +3); Vortex IQ uses UTC. For “today” and “yesterday” cards this can offset by 3 hours. Walk through the reconciliation table. Are 3DS abandonments counted here? No. A 3DS challenge that the customer abandoned ends as StatusId = X and is excluded from this card. They count in viv_threedsecure_abandon_rate. Each marketplace split, do those count separately? No. A parent transaction is one row regardless of how many sub-merchants the payment is split to. Splits are tracked in Viva’s dedicated Marketplace API, not surfaced as separate rows here. Is a recurring rebill counted as one transaction or one subscription? One transaction, per rebill. A monthly subscriber contributes one transaction every billing cycle. The Subscription Active count card is on the roadmap. A failed-then-retried successful transaction, is that one or two? One. Viva consolidates retries on the same MerchantTrxId; only the final successful capture counts. The failed attempts log under viva_decline_rate. Note: if the customer manually re-initiates checkout (creating a fresh MerchantTrxId), that becomes a new transaction. Pay-by-link (B2B invoicing), counted? Yes. Pay-by-link captures use the same Type = Capture rail and contribute when the customer pays. Outstanding pay-by-links are not yet counted; they’re tracked in the dedicated /orders collection. JP Morgan acquisition, any impact on transaction reporting? None operationally. Transaction counts and the API endpoints producing them are unchanged. Why is my Viva count higher than my Shopify order count? Almost always because of recurring rebills, one Shopify subscription order can produce multiple Viva captures over time as the rebill schedule fires. Or, less commonly, because of Viva auto-retries that succeeded after an initial decline (Smart Retry, where enabled).

Tracked live in Vortex IQ Nerve Centre

Successful Transactions is one of hundreds of KPI pulses Vortex IQ tracks across Viva Payments 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 or book a demo to see this metric running on your own data.