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.
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:
Drilling into the highest-leverage cells of the scatter plot:
Five things worth noticing for a Fortune-500 ops + customer-service lead:
- 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
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).
Cross-connector reconciliation:
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-platform 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.