INR disputes correlated with delayed shipments, proves disputes are a fulfilment-ops problem, not fraud. Fix the SLA, not the fraud rules.
At a glance
Cross-channel correlation card that links PayPal Item Not Received (INR) disputes to commerce-platform shipping SLA misses. Fires when the two are statistically correlated > 0.6 over 90 days, evidence that dispute volume is a logistics problem, not a fraud problem. Re-routes operations attention from PayPal Risk settings to fulfilment ops.
| The formula | Pearson correlation between (INR_disputes_filed_per_day) and (orders_with_shipping_delay_per_day) over rolling 90 days. Alert fires at coefficient > 0.6 (statistically meaningful positive correlation). |
| PayPal axis (INR disputes) | T19 events where transaction_subject normalises to “Item Not Received” / “Non-Receipt” classification. Filed-date based, not resolved-date. |
| Commerce axis (shipping delays) | Orders from the connected commerce platform where (actual_ship_date − expected_ship_date) > SLA_threshold OR where tracking shows “in transit > N days without delivery”. SLA threshold defaults: 3 days for first-party fulfilment, 7 days for marketplace / 3PL. |
| Why this card matters (the merchant insight) | INR disputes can come from: (a) the package genuinely didn’t arrive (logistics problem); (b) the customer received it but lied / forgot (fraud / abuse); (c) carrier marked delivered but customer didn’t see it (porch-piracy / address issue). When INR correlates with shipping delays, you have evidence (a) is dominant: real packages, late or lost. Different fix from (b) which requires fraud-rule tightening, or (c) which requires shipping-confirmation UX. |
| Refunds (T11) | NOT counted on PayPal axis. Refunded orders that never disputed don’t appear here. |
| Other dispute types (SNAD, Unauthorised) | NOT counted on PayPal axis. SNAD is a product/listing problem; Unauthorised is fraud. Only INR is logistics-driven. |
| Pending status (P) handling | T19 disputes are counted regardless of resolution status; this is a count of filed disputes, not lost disputes. |
| Currency | n/a (correlation, currency-neutral). Multi-currency stores get a single, valid correlation coefficient. |
| What “shipping delay” means per platform | Shopify: difference between Order.fulfillments.created_at and the SLA-implied expected ship date based on shipping method. BigCommerce: similar via /orders/{id}/shipments. Adobe Commerce: via sales_shipment and sales_order tables. The card uses the connected commerce platform’s data. |
| Page cap | 10,000 PayPal transactions per call; commerce-side platforms have their own paging. 90-day windows on heavy-volume stores can truncate; the correlation calculation is robust to mild truncation but very heavy truncation distorts the coefficient. |
| Time window | 90D (rolling 90 days, longer than other XC cards because INR has a long filing tail; PayPal lets buyers file up to 180 days post-payment, so 90 days captures most filings against a fixed shipping cohort). |
| Alert trigger | correlation > 0.6. Below 0.6 the relationship is too weak to confidently attribute disputes to shipping; above 0.6 the link is statistically meaningful. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your PayPal 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 US-based home-goods brand on Shopify shipping via two carriers (UPS for west-coast, USPS for east-coast). 90-day window: 14 Jan 26 to 12 Apr 26. PayPal carries about 22% of orders. Daily aggregates over the 90 days:| Day | INR disputes filed | Orders with shipping delay (>3 days late) | Notes |
|---|---|---|---|
| Day 1 (14 Jan 26) | 0 | 2 | Quiet baseline |
| Day 12 | 1 | 12 | Snowstorm hit east-coast distribution centre |
| Day 13 | 2 | 18 | Snowstorm continuing |
| Day 14 | 3 | 24 | |
| Day 15 | 2 | 19 | |
| Day 16 | 1 | 11 | Recovery starts |
| Day 17 | 0 | 5 | Back to baseline |
| Day 47 | 1 | 9 | USPS regional route disruption |
| Day 48 | 2 | 16 | |
| Day 49 | 2 | 20 | |
| Day 50 | 1 | 12 | |
| Days 60-90 | mostly 0-1 | mostly 2-5 | Steady state |
- The correlation coefficient is 0.74, well above the 0.6 alert. This is strong statistical evidence: when shipping delays spike, INR disputes spike 1-2 days later. The two events are linked, the disputes are caused by real customers waiting too long for real packages, not by fraud.
- The merchant’s instinct might be wrong. Many merchants seeing 21 INR disputes in 90 days assume “we have a fraud problem, we need to tighten PayPal Risk”. This card proves otherwise: the fraud-fix path is the wrong fix. Tightening Risk would block legitimate customers AND wouldn’t reduce these disputes (they’re from customers who actually paid and actually waited).
- The right fix is operational. Look at the shipping delay clusters: snowstorm + USPS route disruption account for 50%+ of total delays. The fix is (a) carrier diversification (use UPS for east-coast in winter), (b) proactive customer communication on known delays (“your order is delayed due to weather, here’s an updated estimate”), (c) tightening the SLA monitoring threshold so internal ops sees delays earlier and can preemptively reach out. Each step reduces INR disputes meaningfully.
- PayPal Seller Protection covers most of these even when lost. INR disputes are protected as long as the merchant uploaded valid tracking with delivery confirmation. Even if the merchant loses these 21 disputes, Seller Protection refunds the merchant. So the immediate cash impact is small; the real cost is dispute rate (PP Dispute Rate) which counts toward the 1.0% Visa cap regardless of who pays the chargeback.
- What if the correlation were 0.3? Below 0.6 the link isn’t strong. INR disputes could still be high but they’re not driven by shipping delays. Likely cause then: porch piracy (delivered but stolen), address issues (delivered to wrong house), or buyer-side abuse (claiming non-receipt to scam the merchant). The fix shifts to delivery-confirmation UX (signature required for high-value, photo-on-delivery via carriers that support it) or to fraud-pattern detection.
- What if the correlation were negative? Disputes happen on time-shipped orders, which is unusual but possible. Likely cause: a product-quality or expectation-setting issue (customers receive the product but say it didn’t arrive because they’re confused or dishonest). Different remediation needed; check the SNAD share too as customers sometimes file INR when they really mean SNAD.
Sibling cards merchants should reference together
| Card | Why pair it with PP XC INR to Fulfilment |
|---|---|
| PP Dispute Reason Mix | The breakdown of dispute reasons. INR-dominant mix combined with this card’s high correlation = clear logistics signal. |
| PP Dispute Rate | The headline rate. This card explains the why behind INR-driven dispute spikes. |
| PP Seller Protection Coverage | High coverage = INR losses are absorbed by PayPal; low coverage = they hit your cashflow. |
| PP Buyer Protection Win Rate | How well you defend INR cases (with delivery tracking evidence). |
| Shopify Order Fulfilment Time | The commerce-side fulfilment SLA gauge. Pair to see fulfilment-time deterioration before disputes spike. |
| BigCommerce Order Fulfilment Time | BC equivalent. |
| Adobe Commerce Order Fulfilment Time | Adobe equivalent. |
| PP Disputes Open | Live INR queue requiring response. |
| PP Refund Rate | Pre-emptive refunds head off INR disputes; high refund rate + low INR = your customer-service team is doing well. |
Reconciling against the vendor’s own dashboard
Where to look in PayPal Business and your commerce platform: This card combines two upstream sources into a derived correlation. The closest reference views per side: PayPal axis (INR disputes):- PayPal Resolution Center, filter by Reason = “Item Not Received” and the relevant date range.
- PayPal Business → Reports → Disputes report for an aggregated count.
- PayPal Business → Activity → All Transactions, filter by Status = “Disputed” + Subject contains “Not Received”.
- Shopify: Apps → “Fulfilment SLA” reports (Shopify Plus); or custom-built using
Order.fulfillmentsdata. Look for orders withfulfillment_status = unfulfilledpast expected ship date, orfulfilled_at − created_at > SLA. - BigCommerce: BC Analytics → Orders → Fulfilment status, or custom via
/orders/{id}/shipmentsand per-method SLA expectations. - Adobe Commerce: Reports → Sales → Orders, filter by status = “Processing” past expected ship; or SQL on
sales_order+sales_shipmenttables.
- “On-time delivery rate” is a downstream measure (delivery vs ship date); we use ship-date SLA misses (upstream of delivery).
- “Cart abandonment by shipping cost” is a pre-purchase signal, not relevant here.
- PayPal’s Risk dashboard surfaces fraud-flagged transactions, not shipping-correlated INR.
| Reason | Direction of divergence | What to do |
|---|---|---|
| SLA threshold definition. We use 3-day default for first-party fulfilment; your store’s policy may differ (some merchants advertise 5-day or 7-day standard ship). | Coefficient may be off by 0.05-0.15 | Configure SLA threshold per shipping method via manifest if your defaults differ. |
INR subject classification. PayPal’s transaction_subject field has many sub-values; we group them into “INR” using a normalisation rule. Edge cases (e.g. “package received damaged” sometimes goes to INR, sometimes to SNAD) may classify differently. | Tiny | Cross-check by exporting the disputes CSV and grouping by reason. |
| Time alignment. PayPal axis uses dispute-filed-date; commerce axis uses ship-delayed-date. The 1-2 day natural lag between shipping delay and dispute filing is captured in the Pearson correlation, but unusual lag patterns (customers waiting 5+ days before filing) compress the coefficient. | Coefficient may be slightly lower than reality | Use longer aggregation buckets (weekly) for trending stores. |
| Page cap. Both axes have caps; very heavy-volume stores see truncation that distorts correlation. | Either direction | Use shorter windows or the warehouse-backed view. |
| Time zone. PayPal axis is UTC; commerce axis is store timezone. Boundary-day effects on the daily aggregation. | Tiny | Compare equal date ranges. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
pp_xc_inr_to_fulfilment ↔ Stripe equivalent | Stripe doesn’t have an INR-equivalent dispute reason directly; chargebacks under reason “non-receipt” are similar but not identical. | A PayPal-only correlation is normal; PayPal makes INR filing easy via the Resolution Center, Stripe customers tend to refund-request first via the merchant before chargebacking. |
pp_xc_inr_to_fulfilment ↔ commerce platform on-time-delivery rate | Negative correlation expected: as on-time delivery falls, INR rises. | If on-time delivery is high but this card still fires, the INR is from the small minority of late shipments hitting customers hardest, individually rare but each one disputes. |
pp_xc_inr_to_fulfilment ↔ pp_dispute_reason_mix | INR-dominant reason mix should align with this card firing; balanced mix means INR is a smaller share of total. | A mismatch (high INR mix but low correlation) suggests INR disputes are happening but not driven by shipping delays, look for porch-piracy or address-issue patterns. |
Known limitations / merchant FAQs
My INR rate is rising but this card shows correlation 0.3, what does that mean? INR disputes are happening but they’re NOT driven by shipping delays. Likely causes: porch-piracy (delivered but stolen), address issues (delivered to wrong house), buyer-side abuse (claiming non-receipt to scam), or dispute-time-skew (customers filing months after a delivery they actually received). The fix is different from the “speed up shipping” play, you need delivery-confirmation UX (signature required for high-value, photo-on-delivery via supporting carriers) or fraud-pattern detection. What’s the right SLA threshold for “shipping delay”? Defaults: 3 days for first-party fulfilment, 7 days for marketplace / 3PL. If your store advertises 5-7 day standard shipping, the 3-day default over-counts delays. Configure your SLA threshold per shipping method via the manifest. Stores with paid expedited shipping (next-day, 2-day) should set tighter thresholds for those methods to catch breakdowns earlier. Why is the correlation window 90 days? PayPal allows buyers to file INR disputes up to 180 days after payment. A 90-day window captures most filings against a fixed shipping cohort while still being responsive to operational changes. Shorter windows (30 days) miss the lagged filings; longer windows (180 days) make the correlation harder to interpret as new operational changes get diluted by old data. The card fires only after a snowstorm or carrier outage, can I suppress those? Probably not worth it. Weather-driven INR spikes are real customer dissatisfaction even if the underlying cause is “act of God”. The right response is operational: pre-emptive carrier diversification, proactive customer comms during weather events, ship-from-multiple-warehouses for resilience. Suppressing the alert hides a signal that’s worth surfacing to ops leadership. My carrier shows everything as “delivered” but customers still file INR, what’s happening? Common scenarios: (1) USPS marks delivered when scanned at the destination post office, but the carrier hasn’t yet handed off to the customer, this generates “delivered but not received” cases; (2) porch-piracy on package theft after delivery; (3) carrier delivered to wrong address (mail-route confusion). All three look identical on tracking. The fixes diverge: delivery-confirmation UX (photo-on-delivery, signature) for case 1, residential alternatives (lockers, signature) for case 2, address-validation for case 3. This card alone won’t distinguish; combine with carrier-diversification analysis. Does this card help with SNAD or Unauthorised disputes? No, those are separate problems. SNAD is a product / listing accuracy issue (different fix: better photos, sizing charts, copy review). Unauthorised is fraud (different fix: PayPal Risk tuning, fraud-pattern detection). This card is INR-only by design. My store ships from a 3PL, the SLA tracking is opaque, can I still use this card? Limited. The card needs the commerce platform’s fulfilment data to compute “shipping delay”. If your 3PL doesn’t write back accurate ship dates to Shopify / BC / Adobe, the commerce-axis is unreliable and the correlation is meaningless. Push your 3PL for accuratefulfilled_at writeback, or use the 3PL’s own SLA reports as a proxy.
Multi-currency PayPal account, does this card work?
Yes, the correlation is count-based and currency-neutral. INR disputes from any currency are aggregated; shipping delays are time-based. A multi-currency account gets a single, valid correlation coefficient.
What if I want to track INR by region?
Use PP Decline Rate by Card Country and PP Revenue by Country for geographic decompose, but those don’t directly intersect INR disputes. For region-specific INR analysis, export the Resolution Center CSV and pivot by payer_info.country_code or shipping country.
The PayPal axis on this card seems too small (only 21 disputes in 90 days), is that statistically meaningful?
Borderline. Pearson correlation needs at least 30 paired observations for reliability; 21 disputes spread over 90 days gives us 90 daily aggregates which is enough, but with most days at 0 and a few clustering, the coefficient is sensitive to outliers. Treat correlations between 0.5 and 0.7 as “interesting but not conclusive” on low-volume data. Below 30 daily disputes total, this card is more directional than statistical.
Doesn’t PayPal Seller Protection cover all my INR losses anyway?
Mostly yes if you uploaded valid tracking, but the dispute itself still counts toward your dispute rate (PP Dispute Rate) which has the regulatory 1.0% Visa cap. So even when Seller Protection refunds your loss, the underlying customer dissatisfaction shows up in your account-health score. Reducing INR disputes (this card’s lever) is about protecting your dispute rate, not just about cashflow.