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.
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.
What it means. 6.58% is above the alert and the trend is sharp. The cluster on print-quality (3 of 5) points to a specific batch issue at the print-on-demand supplier; all three refunds were on prints ordered between 5 and 12 Apr (within a 7-day window), suggesting one specific print run had calibration issues.
For an Ecwid hobby seller this is exactly the canary the card is meant to catch. The seller’s individual orders are personal; three “the print arrived banded” emails is emotionally significant in a way that 50 of those would feel for a larger brand. The card validates the seller’s gut feeling that “something is off this week” with hard data.
The action: contact the print-on-demand supplier (typically Printful, Inktreon, or similar for UK photographers) with the three order numbers; they will reprint or credit. Re-run a calibration test print before fulfilling new orders. Update the packaging spec for the damaged-in-transit case (mailing tubes vs flat-pack rigid mailers; flat-pack is more reliable for A3 prints).
Refund-rate trajectory should drop back to ~2 to 3% within 30 days once the bad batch is cleared.
Sibling cards merchants should reference together
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:
Internal identity:
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.