At a glance
A scatter-plot view that joins CyberSource chargeback patterns to commerce-platform return / refund-request rates by SKU and customer. Answers the diagnostic question “are our customers escalating to chargebacks instead of using normal return / refund flows, and which SKUs are driving it?” High correlation (>0.6) means customer-service or fulfilment failure is pushing buyers into the chargeback queue when they should be doing returns; this is fixable but signals real ops dysfunction.
| The formula | Pearson correlation between (a) CS chargeback events with reason code 4855 / 4853 / Mastercard 4855 / 4837 grouped by SKU + customer, and (b) the connected commerce platform’s return-or-refund-request rate by the same SKU + customer. Computed over 90D rolling window. |
| Reason codes included in the dispute side | Visa 4855 (goods/services not received), Visa 4853 (cardholder dispute / fraud, when the merchant suspects friendly-fraud), Mastercard 4855 (non-receipt), Mastercard 4837 (no cardholder authorisation, when the merchant suspects friendly-fraud). These are the disputes most likely to overlap with legitimate customer-side complaints that should have flowed through return / refund channels. |
| Reason codes excluded | Visa 4863 (doesn’t recognise, typically descriptor issue, not product issue), Mastercard processing-error codes, Amex billing-dispute codes that are explicitly NOT product-related. |
| Commerce-side return-rate measurement | Reads the connected commerce platform’s return-and-refund-request data (Adobe Commerce return RMA, Shopify refund_request, BigCommerce returns API). Per SKU and per customer to enable correlation. |
| Why correlation as a metric? | A scatter chart of “this SKU has X% disputes AND Y% returns” tells you whether your customer journey for a problem product has a healthy escape valve (high returns, low disputes, customers using the right channel) or a broken one (high disputes, low returns, customers can’t get returns done so they escalate). Correlation between the two is the headline number; the scatter plot is the diagnostic. |
| Required connectors | CyberSource AND a commerce-platform connector with return / refund tracking. Card grays out without a commerce sibling. |
| What it doesn’t count | (1) Chargebacks unrelated to product (descriptor-driven 4863, fraud-only 4853); (2) returns that didn’t escalate to refund (some platforms support exchange-only returns); (3) customers who refunded and ALSO disputed (rare but possible). |
| Currency | n/a (correlation coefficient, dimensionless). |
| Refunds | The denominator side captures refund-request volume; refunds issued AS a dispute resolution don’t double-count. |
| Time window | 90D. Long enough to accumulate enough disputes per SKU for stable correlation; short enough to reflect current ops state. |
| Refresh cadence | Daily. |
| Alert trigger | correlation > 0.6. Above 0.6 indicates strong overlap between disputes and returns at the SKU / customer level, meaning the dispute queue is mostly customers escalating from would-be returns. Actionable signal that customer-service or returns infrastructure needs attention. |
| Roles | owner, finance, operations, customer-service |
Calculation
Calculated automatically from your CyberSource 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 North American consumer electronics retailer running CyberSource for ecommerce + Adobe Commerce for the storefront. The 90-day window covers 14 Jan 26 to 12 Apr 26. The merchant ships ~$140M / month across 8,200 SKUs. The card shows a scatter plot with each point representing a SKU; X-axis is dispute rate, Y-axis is return-request rate. Correlation coefficient computed across all SKUs with ≥ 50 sales in the period. The aggregate state:| Statistic | Value |
|---|---|
| SKUs with ≥ 50 sales (in scope) | 2,840 |
| Mean dispute rate per SKU | 0.71% |
| Mean return-request rate per SKU | 4.8% |
| Pearson correlation (this card’s headline) | 0.74 |
| Quadrant | SKUs | Dispute rate | Return rate | Diagnosis |
|---|---|---|---|---|
| High dispute, high return (the big problem cluster) | 142 SKUs | 1.8-3.4% | 12-18% | Product-quality issue + ops dysfunction; customers trying both channels |
| High dispute, low return (returns infrastructure broken) | 38 SKUs | 1.5-2.8% | 1-3% | Customer-service failure; can’t get returns processed, escalate to chargeback |
| Low dispute, high return (healthy escape valve) | 412 SKUs | 0.2-0.4% | 8-15% | Returns working as intended; product issues handled correctly |
| Low dispute, low return (well-performing SKUs) | 2,248 SKUs | 0.1-0.3% | 1-4% | Healthy mix; no action needed |
- Correlation 0.74 is well above the 0.6 alert threshold. This says SKUs that get disputed are also SKUs that get returned (and vice versa), which means the chargeback queue is largely customers who could have / should have used the return process. Per-SKU root cause analysis is now actionable.
- The 38 “high dispute, low return” SKUs are the highest-priority remediation. Customers can’t (or won’t) get returns done, so they escalate to chargebacks. Common causes: (a) returns flow timing-out or breaking on these specific products (heavy items, fragile, hazmat); (b) customer-service queue too long, customer gives up and disputes; (c) product page not surfacing return options clearly. Drilling into these SKUs and fixing the returns flow typically drops the dispute count on these SKUs by 50-70% within 60 days.
- The 142 “high dispute, high return” SKUs are a product-quality signal. When BOTH disputes and returns are elevated, the underlying issue is the product itself: defects, mis-described listings, photos vs reality, or product / packaging design issues. The action is product-team escalation: review the SKU, audit the listing, consider re-merchandising or delisting if the SKU is loss-making after factoring in dispute losses + return-cost.
- The 412 “low dispute, high return” SKUs are healthy. Returns are absorbing the legitimate dissatisfaction without escalating to chargebacks. This is what good ops looks like: customers who don’t love a product return it through the proper channel, which costs less than a chargeback (no chargeback fee, no dispute-ops time, no VDMP-rate-impact). The merchant should NOT try to reduce returns on these SKUs without understanding why.
- The cross-platform diagnostic is the entire point. Without this card, the dispute-ops team would see 2-3% disputes on a SKU and assume it’s friendly fraud or product fraud. With this card, they can see “this SKU has 3% disputes BUT 0.5% returns, something is wrong with our returns flow for this SKU specifically”. That’s an actionable diagnostic the card is uniquely positioned to provide.
Sibling cards merchants should reference together
| Card | Why pair it with Disputes vs Returns Correlation |
|---|---|
| Dispute Rate | The aggregate; this card is the per-SKU diagnostic. |
| Chargeback Reason Codes | The reason-code split feeding the dispute side. |
| Open Chargebacks | The live ops queue; many of these will be SKUs from the high-dispute clusters. |
| Dispute Win Rate | Win rate on per-SKU disputes; high-dispute / low-return SKUs often have low win rates because the customer’s complaint is legitimate. |
| Recoverable Revenue (decline-driven) | The decline-side cross-channel companion. |
| Decline Spike vs Checkout Funnel Drop | Diagnostic chart for live decline-driven incidents. |
| 3DS Friction Revenue Loss | The 3DS-side cross-channel revenue loss. |
| Adobe Commerce / Shopify / BigCommerce returns / RMA | The commerce-side return-rate data feeding the Y-axis. |
Reconciling against the vendor’s own dashboard
Where to look in CyberSource Business Center (EBC2): This card has no direct EBC2 counterpart, it joins CS dispute data to commerce-platform return data. The CS-side input data lives at:- EBC2 → Decisions → Chargebacks → Case Management, with reason-code filtering for 4855 / 4853 / Mastercard 4855 / 4837.
- EBC2 → Reports → Chargeback Detail Report, transaction-level disputes with SKU metadata (when the merchant passes SKU in the auth request).
| Reason | Direction | What to do |
|---|---|---|
SKU passing. Disputes only carry SKU metadata if the merchant included productSKU in the original auth request. Merchants who don’t send SKU at auth time can’t compute this card; the card grays out. | Either direction (SKU coverage gap). | Update the auth-request payload to always include SKU. |
| Reporting API extraction lag. Reporting v3 overnight batch on the chargeback side. | Vortex IQ may lag EBC2 2-6 hours on most-recent day. | Negligible at 90D window. |
| Time zone. EBC2 uses merchant-account tz; we use UTC. | Boundary-day drift. | Negligible at 90D window. |
| Sample size. SKUs with < 50 sales in 90D are excluded from the correlation. | Long-tail SKU information not surfaced. | Adjust the volume floor in the manifest if needed. |
| Returns attribution lag. Some commerce platforms lag refund-issued data by 1-3 business days. | Tiny drift. | Negligible at 90D window. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
cs_xc_disputes_to_returns ↔ aggregate cs_dispute_rate | The per-SKU disputes here aggregate to the merchant-wide rate. | Identity (subset). |
cs_xc_disputes_to_returns ↔ commerce platform’s per-SKU return-rate report | The Y-axis of the scatter plot is sourced from the commerce platform; should agree exactly. | Discrepancy = data-pipeline issue. |
cs_xc_disputes_to_returns ↔ cs_xc_recoverable_revenue | Different friction sources (returns-flow failure vs decline-driven). Both contribute to total cross-channel revenue loss. | Independent. |
Known limitations / merchant FAQs
My correlation is 0.74. Is that good or bad? Bad-ish. A correlation of 0.74 means SKUs with high disputes also tend to have high returns (and vice versa), which says customers are escalating to chargebacks instead of using the return process for the same problem products. The threshold is 0.6 specifically because below that the two channels are operating mostly independently (returns absorbing legitimate complaints, disputes mostly being friendly fraud or descriptor-driven), which is healthy. Above 0.6 indicates the dispute queue is mostly customers who could have / should have used returns. My correlation is 0.3. Should I be worried? No, the opposite, correlation of 0.3 says returns and disputes are mostly independent. Returns are absorbing legitimate complaints (the proper channel) and disputes are mostly friendly fraud / descriptor / fraud-side issues that returns wouldn’t have caught anyway. This is what healthy cross-channel ops looks like. No action needed beyond regular dispute-ops work. The card flagged but my customer-service team thinks they’re handling returns fine. How do I dig in? Drill into the “high dispute, low return” SKU cluster. These are the SKUs where the returns flow is failing while disputes are succeeding. Common findings: (a) returns timing-out for heavy / fragile SKUs because shipping-back logistics fail; (b) customer-service ticket queues backed up beyond the customer’s patience threshold (3, 7 days); (c) returns flow on the website not surfacing properly on mobile. The customer-service team’s perception is often based on tickets they actually saw; the customers escalating to disputes are the ones whose tickets they didn’t see (because the customer gave up first). What if my SKU coverage is incomplete? The card requires the merchant to pass SKU metadata in the original CyberSource auth request (productSKU field). Merchants who don’t pass SKU end up with un-attributable disputes that can’t be joined to commerce-side return data. The fix is updating the auth-request payload to always include SKU. CyberSource integration guides cover this; it’s a config update, not a code change.
Why are Visa 4863 disputes (doesn’t recognise) excluded?
Because they’re typically not product-related. 4863 disputes are descriptor-driven, the customer doesn’t connect the brand on their statement to the merchant’s identity. Improving the descriptor (clearer brand name, support phone) prevents these; they have nothing to do with returns. Including them would inflate the correlation falsely.
My SKU mix is huge. Does the card scale?
The card aggregates to SKUs with ≥ 50 sales in the period (the volume floor). For a typical enterprise merchant with 5,000-20,000 SKUs, this surfaces 1,000-4,000 SKUs in the in-scope set, which is enough for stable correlation but not so many that the scatter is unreadable. Adjust the volume floor in the manifest if the merchant needs longer-tail visibility.
The “high dispute, low return” cluster is small (38 SKUs). Is it really worth investigating?
Yes. Even a small cluster typically represents 10-25% of total monthly disputes (because the per-SKU dispute rate is elevated). Fixing the returns flow for this cluster typically drops the cluster’s dispute rate 50-70%, which translates to a meaningful chunk of total dispute volume. ROI is high: 38 SKUs is a manageable audit; the dispute reduction is meaningful.
Can I exclude friendly-fraud disputes from the calculation?
Not directly. Friendly-fraud is hard to identify mechanically (the dispute reason looks the same as legitimate fraud to the card-network). The card’s design, including 4853 / 4837 because some are friendly-fraud and some are real product complaints, is intentional. Drilling into specific high-dispute SKUs and reading the actual dispute evidence often reveals which is which; this card is the diagnostic that tells you which SKUs to drill into.
My commerce platform doesn’t have detailed return data. Can I still use this card?
Partially. If the commerce platform exposes only refund counts (not return-request counts), the card uses refunds as a proxy. This works for most ecommerce merchants where refund and return are essentially synonymous. For merchants with exchange-only returns or store-credit returns, the proxy is less accurate; the card flags this and reduces its confidence.
My multi-currency global merchant, does this card work?
Yes. The correlation is dimensionless (rate-vs-rate), so multi-currency merchants get a single valid correlation across the whole merchant. Per-region drilldowns are available if the merchant configures region-specific SKU routing.