At a glance
The count of refund events processed in the period: how many discrete refunds (full or partial) Viva returned to customers. Distinct from refund value (EUR amount); operations teams care about volume because each refund event consumes staff time, customer-service tickets, 3PL handling, regardless of size.
| What it counts | COUNT(refunds) issued via POST /api/transactions/{id}/refunds in the period. Each successful refund call counts as one event. |
| API endpoint | /api/transactions/{id}/refunds on the Smart Checkout API. |
| Currency | Currency-neutral (count of events). |
| Refund timing | Issue date (when the merchant initiated the refund). |
| Disputes / chargebacks | Excluded. Disputes are buyer-initiated; this card is merchant-initiated only. |
| Recurring rebills | Counted. A refunded rebill is one event. Cancelling a future rebill is not. |
| Channels | Online + POS unified. POS refunds (in-store returns) and online refunds both count. |
| Time window | 30D vsP. |
| Alert trigger | +25% relative spike vsP (volume sentinel; absolute thresholds are vertical-dependent). |
| Roles | owner, 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 pan-EU online beauty retailer (“Cyclades Beauty”) on Smart Checkout, no POS, monthly subscription rebills + one-time orders. Window 03 Apr 26 to 02 May 26.| Refund category | Count | Avg refund value | Notes |
|---|---|---|---|
| Full refunds (returns within 30 days) | 84 | EUR 42 | Standard return policy |
| Partial refunds (shipping-only) | 38 | EUR 6 | Shipping refund where customer kept goods |
| Partial refunds (item swap) | 22 | EUR 18 | Customer kept some items, returned others |
| Goodwill refunds (customer service) | 12 | EUR 28 | Service-recovery gestures |
| Recurring rebill refunds | 6 | EUR 35 | Subscription cancellations + immediate refund |
- 84 full refunds (52% of events) is the dominant operational driver. These are the events that consume the most workflow time: customer-service ticket, return label, 3PL receipt, inventory check, refund processing. Reducing the full-refund count even by 10% (8 refunds avoided) saves roughly 1 staff hour per period.
- 38 shipping-only partial refunds is unusual concentration. This typically signals shipping SLA misses (parcels arriving 1 to 2 days late and customers requesting shipping refund as compensation). If 3PL performance has dropped, this number swells. Cross-reference against delivery-tracking data.
- 6 recurring rebill refunds is a healthy churn signal. Subscription cancellations are normal; what matters is the rate of cancellations relative to active base. If active subscribers are ~ 5,000 and cancellations + refunds run at 6/month, monthly churn is 0.12% which is excellent.
- Operations cost vs revenue impact. 22 staff hours at EUR 25/hour fully loaded = EUR 550 in process cost, plus EUR 16 in Viva refund fees. Total operational cost ~EUR 566 to process EUR 4,950 of refunds = ~ 11% process overhead. Reduce this by automating low-touch refund paths (shipping-only auto-approve under EUR 10).
- JP Morgan acquisition relevance: refund processing is unchanged. The Smart Checkout
POST /refundsendpoint, fees, and workflow are identical pre- and post-acquisition.
Sibling cards merchants should reference together
| Card | Why pair it with Refund Volume |
|---|---|
viv_refund_rate | The rate equivalent (count ÷ transactions). |
viva_refund_value | The EUR amount over the same period. |
viva_refund_rate | Sibling value-rate equivalent. |
viva_refunds_trend | Time-series view, catches volume movement before period close. |
viv_total_transactions | The base population that refunds were carved from. |
viv_dispute_rate | Refund-as-prevention; high refund volume often correlates with low dispute rate. |
Stripe stripe_refund_volume / PayPal pp_refund_volume | Cross-PSP refund-event comparison. |
Reconciling against the vendor’s own dashboard
Where to look in the Viva Payments Dashboard: viva.com/business/account/login. Closest comparable view:Viva Business → Sales → Refunds → Count tile (period filter)The Dashboard refund count and our card should match within a few units once time-zone is reconciled. Why our number may legitimately differ:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Athens / Cyprus timezone vs UTC. |
| Refund-event counting | Marginal | We count each POST /refunds call as one event. Multiple partials on a single transaction count as multiple events. |
| In-flight refunds | Ours lower in real-time | Refunds initiated but not yet confirmed by the network are not yet counted. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
viv_refund_volume ↔ commerce-platform refund event count | Should match for Viva-paid orders | Commerce platform may include non-Viva-method refunds. |
viv_refund_volume ↔ stripe.stripe_refund_volume | Cross-PSP comparison | Different traffic, different return propensity. |
Known limitations / merchant FAQs
“Refund volume vs refund value, why both?” Operations cares about volume (each event has fixed processing burden); finance cares about value (each event reduces revenue). Both metrics surface different problems: a wave of small partial refunds raises volume without much value impact (3PL or shipping issue); one large refund raises value without changing volume (single bad order or B2B return). “Partial refund counts the same as full refund?” Yes, in this card. EachPOST /refunds call is one event. A transaction with three partial refunds (week 1 shipping, week 2 item, week 3 second item) counts as three events here.
“Why is my refund volume spiking?”
Common causes in order: (1) shipping delays / 3PL performance issues (drives small shipping-only refunds), (2) recent product launch with quality issues (drives full refunds), (3) sizing / spec mismatch on fashion (drives full refunds), (4) customer-service team handling tickets too generously (drives goodwill refunds), (5) seasonal returns surge after major holiday peak (drives full refunds 2 to 4 weeks post-peak).
“Operations cost per refund, how to estimate?”
Rule of thumb: 5 to 12 minutes per refund event for a steady-state team. Multiply by your fully-loaded staff cost and add Viva’s per-refund fee. Automate low-touch paths (shipping-only auto-approve under EUR 10, expired-subscription cancellations) to recover 30 to 50% of staff time.
“Recurring rebill refunds, why are they so few?”
Subscription cancellations usually don’t trigger a refund of the most recent rebill, the customer’s service ends at next billing cycle. Refunding the most recent rebill is a goodwill gesture (or required by some terms-of-service); merchants that auto-refund-on-cancel are over-generous. Track this metric as a process discipline indicator.
“Multi-currency, blended count?”
Yes. A GBP refund and an EUR refund both add 1 to count.
“Volume vs trend, should I look at both?”
Yes. The volume metric (this card) shows period total; viva_refunds_trend shows the daily series. Sudden spikes in the trend often precede the period-aggregate alert by 5 to 7 days, useful for early intervention.
“JP Morgan acquisition, anything affecting refund processing?”
No. Refund mechanics, fees, and API are unchanged.
“How do refund events relate to chargebacks?”
Inverse correlation typically. Merchants who process more refunds proactively see fewer disputes and chargebacks. The math: a customer who refunds at week 1 doesn’t escalate to bank at week 3.