At a glance
Average successful transaction value across Helcim rails (Helcim Online + Smart Terminal + Recurring + virtual terminal). The denominator-aware reading of revenue: useful when total volume is steady but ticket size is drifting up or down.
| What it counts | SUM(amount WHERE status='APPROVED' AND type IN ('purchase','capture')) ÷ COUNT(*) over the window, per currency. |
| API endpoint | GET /v2/card-transactions on Helcim API v2. |
| Pricing model | Helcim’s interchange-plus markup is per-transaction (flat fee + percentage). Average ticket size affects effective rate: smaller tickets pay disproportionately more in per-transaction fees, larger tickets pay less. A drifting average ticket therefore shifts your effective rate even if interchange-plus terms haven’t changed. |
| Currency | Per-currency, no FX. CAD-only, USD-only, or both displayed separately. A CAD merchant accepting USD will see CAD avg and USD avg as separate rows. |
| Refunds | Refunds excluded from numerator and denominator. |
| Disputes | Disputes still included (the original capture was successful). |
| Failed / declined | Excluded. Only APPROVED rows count. |
| 3DS abandons | Excluded (those captures never completed). |
| Channels | Online + POS + Recurring blended. POS and recurring typically pull the average up (POS tickets tend to be larger for retail; recurring is fixed-amount); pure-online may pull it down depending on category. The per-channel split lives in hel_top_payment_methods. |
| Time window | 30D vsP (default). |
| Alert trigger | ±20% move vs prior period (move in either direction is flag-worthy). |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Helcim 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 representative reading of Average Transaction for a typical merchant on Helcim. The card reports the current period value alongside a comparison against the previous period. Direction matters: rising values may be healthy or concerning depending on the underlying metric. Cross-reference the siblings below to triangulate cause when the value moves outside expected range. For deeper investigation, use Vortex Mind to trace upstream causes; for natural-language exploration, ask Ask Viq.Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
hel_total_transactions | Volume sibling: Total Transactions. |
hel_total_volume | Volume sibling: Total Volume. |
hel_volume_trend | Volume sibling: Volume Trend. |
hel_avg_settlement_days | Settlement sibling: Avg Settlement Time (days). |
hel_chargeback_rate | Refunds & Disputes sibling: Chargeback Rate. |
Reconciling against the vendor’s own dashboard
Where to look in Helcim’s own dashboard: The Helcim dashboard surfaces this metric (or its components) under the relevant report section. Confirm period boundaries and filter settings match the Vortex IQ profile to reconcile cleanly. Why the Vortex IQ value may legitimately differ:| Reason | Direction | What to do |
|---|---|---|
| Period boundary. Vortex IQ uses 30-day rolling by default; vendor dashboards may use calendar periods. | Variable | Match the period range. |
| Time zone. Vendor uses account time zone; Vortex IQ aligns to merchant reporting time zone. | Marginal | Confirm time zone match. |
| Filter scope. Profile-level filters (channel, B2B, test orders) may narrow the Vortex IQ view. | Variable | Match filter settings. |