First canary on a quality issue or deploy regression.
At a glance
Refunded orders / total orders over rolling 30D. The first canary on quality issues, sizing problems, or post-purchase delivery breakdowns. For Ecwid hobby stores running a small catalogue, a single bad batch on the print-on-demand or fulfilment supplier shows up here first.
| What it counts | COUNT(orders WHERE has_refund = true) / COUNT(orders WHERE PAID) over rolling 30D. |
| API endpoint | Refund events from GET /v3/{store-id}/orders (refund records nested in order objects); webhook updates on order.refunded. |
| What “refund” includes | Any refund logged in Stripe or PayPal that the merchant captured back to Ecwid; full or partial both count as one refund. |
| What it excludes | Cancelled-before-payment orders; pending refund disputes (count once resolved). |
| VAT / tax / shipping | Order-count rate; values not the variable. |
| Cancellations | Excluded. |
| Currency | Dimensionless. |
| Time window | 30D vsP. |
| Alert trigger | >5%. Same threshold as the other ecommerce connectors; common-rule-of-thumb floor. |
| Sentiment | refund_rate. Inverse gauge. |
| Roles | owner, operations, finance. |
Calculation
Calculated automatically from your Ecwid 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 small UK hobby photographer running an Ecwid widget on their WordPress blog, rolling 30D ending 27 Apr 26.| Metric | This 30D | Prior 30D | Change |
|---|---|---|---|
| Total orders | 76 | 64 | +18.8% |
| Refunded orders | 5 | 2 | +150% |
| Refund Rate (this card) | 6.58% | 3.13% | +3.45pp |
| Reason | Count |
|---|---|
| Print quality (banding visible on A3) | 3 |
| Damaged in transit (poor packaging) | 1 |
| Wrong print delivered | 1 |
Sibling cards merchants should reference together
| Card | Why it matters next to refund rate | What the combination tells you |
|---|---|---|
| Total Revenue | Cost of the refunds. | Revenue rising + refund rate rising = the lift is being clawed back; net is flatter than headline. |
| Total Orders | Denominator. | Order count rising slowly + refund count rising fast = ratio worsens; investigate. |
| Top Products | SKU concentration. | Refunds usually concentrate on 1 to 2 SKUs; identify and fix the offender. |
| Out-of-Stock Products | Adjacent quality. | Forced-substitution OOS often correlates with refunds (buyer got the wrong size / colour). |
| Conversion Rate | Reputation downstream. | High refund rate eventually shows up as falling CR (negative reviews, returning visitors not buying). |
| Repeat Purchase Rate | Long-term cost. | Refunders are 60 to 80% less likely to return; persistent refund-rate rise erodes repeat rate. |
| New Customers | First-impression. | New customers refunding at high rate = brand-trust acquisition cost rising. |
Reconciling against the vendor’s own dashboard
Where to look in Ecwid’s own dashboard:
Ecwid Control Panel (my.ecwid.com) -> Reports -> Order list -> filter by “Has refund”
Count the filtered list against the same window’s total order count.
Why our number may legitimately differ from Ecwid’s Control Panel:
| Reason | Direction | Why |
|---|---|---|
| Partial refund counting | Marginal | A partial refund counts as one refund in our card; some Ecwid views show partial-refund value rather than count. |
| Time zone | Boundary days | Ecwid uses store-local; we use UTC. |
| Pending disputes | Theirs higher | Ecwid sometimes shows dispute-in-progress as refunded immediately; we wait for resolution. |
| Cancellation handling | Either | Cancelled-after-payment orders trigger a refund in Stripe; we treat them as cancellations and exclude here to avoid double-count. |
| Sync lag | Marginal | Webhook-driven; under 60s. |
ecwid_refund_rate = COUNT(refunded orders) / COUNT(paid orders) over the same window.
Known limitations / merchant FAQs
What is a normal refund rate for an Ecwid hobby store? 2 to 5% for print, zine, and other physical-product hobby sellers. Hobby Ecwid stores often beat industry-average refund rates because the catalogue is small, the merchant cares deeply, and personalised customer service catches issues before they escalate to formal refunds. Why is the alert at 5% if my baseline is 2 to 3%? 5% is the universal floor across ecommerce; below 5% is “good”, 5 to 8% is “watch”, 8%+ is “act now”. The threshold is configurable per-merchant if a hobby seller wants tighter monitoring. My refund rate spiked from 3% to 7% in one week. What probably happened? Almost always one of: (1) a bad batch from a print-on-demand or fulfilment supplier (cluster of refunds on one product), (2) a courier issue (cluster of “damaged in transit” or “never arrived”), (3) a recent product launch where the photography over-promises vs reality. Drill down to the per-SKU refund concentration to identify which. Does this include Stripe disputes? Disputes that resolve as refunds count once resolved. Disputes that resolve in the merchant’s favour (chargebacks reversed) do not count. The drill-down view shows pending disputes separately. My subscription product had a churn refund. Does that count? Yes. A subscription cancellation that triggers a pro-rata refund counts as one refund event. Cancellations without refund (just stopping future billings) do not. Why does my Ecwid Control Panel show a different rate? Usually time zone or partial-refund handling. We count partials as full-refund events for the rate; some Ecwid views show partial-refund value as a fraction. Reconcile by checking the order-list filterHas refund = yes over the same window.
My catalogue is just 12 products; one bad week tanks my rate. What do I do?
For very small catalogues, the rate is volatile by design. Look at the absolute count (1 vs 5 refunds) more than the percentage; one print refund is normal life, five in a week is a batch issue. Configure the alert threshold higher (e.g. 10% or absolute count >5) if 5% generates too many false positives.
Does this trigger an automatic Stripe / PayPal disable if too high?
No. The card is informational; it does not modify your Stripe / PayPal account. Stripe will independently raise concerns at ~1% chargeback rate; this card is a different (and earlier) signal than chargeback rate.
How quickly does this update after I issue a refund?
Webhook-driven; under 60 seconds typically. The refund appears in the next dashboard render.