How to reduce losses from paper claims and false delivery disputes: provider-specific evidence playbooks
Updated
Most merchants losing money to paper claims and false delivery disputes aren't losing because delivery didn't happen. They're losing because the evidence package didn't match what the provider required, or the response arrived after the deadline.
This guide is for e-commerce operations and risk teams who already understand the basics of dispute handling and need a precise, provider-anchored playbook. You'll get evidence checklists per provider, annotated example packages, deadline timelines, and rejection-prevention validation rules for Klarna, PayPal, Visa, and Mastercard.
What you'll need before starting:
Access to your carrier's track-and-trace data (last-mile scan events, GPS coordinates if available)
Order management system records (checkout shipping address, customer details, order value)
A process for capturing proof of delivery (POD) photos, signature scans, and delivery timestamps at the carrier level
Dedicated intake workflows that flag disputes the moment they arrive
Difficulty: Intermediate to advanced. Teams already managing disputes manually will find this directly actionable.
Time to implement: One to two hours to build per-provider evidence packages from existing data; ongoing process takes minutes per dispute when infrastructure is in place.
Why generic proof of delivery fails at the provider level
The most common paper claims loss prevention mistake is treating proof of delivery as a binary: either you have a photo, or you don't. That framing misses how disputes actually get decided.
Every major payment provider operates a reason-code-anchored rulebook. Evidence that doesn't map directly to the required fields for the active reason code gets rejected regardless of its factual accuracy. A delivery photo with GPS metadata does nothing for a Klarna Item Not Received dispute if it isn't accompanied by a tracking ID from the last-mile carrier, the full recipient name, and a matching shipping address. Similarly, a Visa chargeback under reason code 13.1 (Merchandise Not Received) requires a different evidence structure than one filed under 10.4 (Other Fraud). Submitting the same generic POD bundle across both loses the second case even if it won the first.
The operational reality is that two failure modes drive the majority of avoidable losses:
Missing or mismatched required evidence fields
Responses submitted after the provider's deadline
Both are process failures, not evidence failures. The goods were delivered. The record exists. The merchant loses anyway. Understanding this distinction is the starting point for building a dispute management system that actually recovers revenue.
Klarna evidence checklist and example package
Klarna's Merchant Protection Program covers two primary dispute types: Item Not Received (INR) and Significant Deviation (faulty goods or goods not matching the listing). Each requires a distinct evidence bundle.
Step 1: Identify the dispute type
When a Klarna dispute arrives, the first action is classifying it:
INR / goods not received: The customer claims the order never arrived.
Significant Deviation: The customer claims the goods arrived but differ materially from the listing, or are defective.
The Klarna Merchant Protection Program evidence requirements differ for each type, so misclassifying the dispute before building your package wastes time and risks submitting the wrong evidence set.
Step 2: Assemble the INR evidence bundle
For Item Not Received disputes, Klarna requires the following fields (required by provider spec per Guzco first-party documentation):
Evidence field | Status | Notes |
|---|---|---|
Tracking ID from last-mile carrier | Required | Must be the final-leg carrier scan, not the upstream handler |
Full recipient name | Required | Must match the name on the Klarna order |
Shipping address match confirmation | Required | Checkout address must match delivery address exactly |
Signature confirmation | Required for orders above 750 USD | Must be a carrier-captured signature, not an internal record |
Delivery timestamp (scan event) | Required | Date and time of confirmed delivery event |
POD photo with GPS coordinates | Strongly recommended | Increases win probability; include metadata if available |
Carrier delivery status page (screenshot or PDF export) | Recommended | Provides a readable summary for non-technical reviewers |
Rejection triggers to preempt:
Address on the POD does not match the Klarna checkout address field-for-field (even minor formatting differences can cause rejection)
Signature missing on orders exceeding the 750 USD threshold
Tracking ID is from a consolidator or relay carrier, not the last-mile carrier that completed delivery
Evidence submitted after Klarna's case deadline
Step 3: Assemble the Significant Deviation evidence bundle
Klarna gives merchants 21 days from first contact to resolve a Significant Deviation claim. That window runs from Day 0 (claim open) to Day 21, so internal evidence assembly must begin immediately on intake.
Evidence field | Status | Notes |
|---|---|---|
Product listing screenshots (at time of sale) | Required | Must show the exact product description, images, and specifications |
Defect photos or video submitted by customer | Required | Include as received; do not edit |
Your rebuttal photos/video of the shipped item | Required | Time-stamped warehouse or packing photos if available |
Pre-shipment quality check records | Required | Packing list, QC sign-off, or packing video |
Communication log (customer contact attempts and outcomes) | Required | Date-stamped messages; include attempted resolution offers |
Return proof (if return was requested and completed) | Conditional | Only if Klarna required a return as part of resolution |
Description mismatch analysis (side-by-side comparison) | Recommended | Useful when the customer's claim is factually inaccurate |
Checkpoint: Before submitting, verify that resolution lands before Day 21. Guzco's Klarna handling targets resolution by Day 11 of 21 to preserve decision latitude. Waiting until Day 20 leaves no buffer for submission errors.
Annotated example evidence package: Klarna INR
File naming convention: [OrderID]_KLARNA_INR_[YYYY-MM-DD]
PayPal evidence checklist and example package
PayPal disputes move through two stages: inquiry and claim. Most merchants lose winnable disputes by treating the inquiry phase as optional. It isn't.
Step 1: Respond during the inquiry phase
When a buyer opens an inquiry, PayPal gives the seller a window to respond directly before the buyer can escalate to a formal claim. Per PayPal's help documentation, sellers should respond within 10 days. The buyer can escalate to a claim within 20 days of opening the dispute (PayPal Purchase Protection Program, updated January 26, 2026). An unanswered inquiry almost always becomes an escalated claim, and escalated claims are resolved by PayPal's review team rather than directly with the customer.
Action: Set an internal alert to respond within 48-72 hours of inquiry receipt, not at the edge of the 10-day window.
Step 2: Verify Seller Protection eligibility before building your package
Seller Protection coverage determines whether your response can succeed at all. Before building any evidence bundle for a PayPal Item Not Received dispute, confirm:
The shipping address on the PayPal transaction matches the address you shipped to (address mismatches void Seller Protection coverage)
Signature confirmation was captured for high-value orders (threshold varies by country; apply it broadly for orders above $250)
The item type is eligible (digital goods, certain services, and custom items are typically excluded)
Address mismatches, missing signature confirmation on high-value orders, and ineligible item types should be flagged at checkout and pre-shipment, not at the dispute stage. Discovering an eligibility failure after the dispute arrives means you're building a package for a case you structurally cannot win.
Step 3: Build the INR evidence bundle for PayPal
Evidence field | Status | Notes |
|---|---|---|
Proof of shipment (carrier receipt or label scan) | Required | Must show shipment to the transaction address |
Delivery confirmation from carrier | Required | Must show delivered status with date |
Shipping address match (PayPal transaction vs. carrier) | Required | Exact address field match required for Seller Protection |
Signature confirmation record | Required for high-value orders | Carrier-captured; not a customer acknowledgment email |
Tracking number tied to the specific transaction | Required | Link tracking to the PayPal order ID in your response |
Carrier name and service used | Required | DHL, UPS, FedEx, etc.; include service level |
Communication log with buyer | Recommended | Shows good-faith resolution attempts |
Order details (item, quantity, value) | Recommended | Ties the shipment record to the specific transaction |
Step 4: Build the SNAD (Significantly Not As Described) evidence bundle
Evidence field | Status | Notes |
|---|---|---|
Product listing at time of sale | Required | Exact listing description and images |
Packing/quality documentation | Required | Pre-shipment photos or QC records showing item condition |
Rebuttal to customer's specific claim | Required | Point-by-point response to the stated deviation |
Customer communication log | Required | All messages between buyer and seller |
Return instructions (if issued) | Conditional | If PayPal ordered a return as part of resolution |
Annotated example evidence package: PayPal INR
File naming convention: [PayPalCaseID]_PP_INR_[YYYY-MM-DD]
Rejection triggers to preempt: Evidence not attached as a file (pasted text is not accepted), address mismatch between PayPal order and carrier delivery record, missing delivery confirmation for the transaction address, response submitted after the deadline.
Visa and Mastercard chargeback representment requirements
Card network chargebacks are reason-code-driven. The reason code determines the required evidence set, the formatting requirements, and the response deadline. Submitting evidence that doesn't directly address the specific reason code results in a failed representment regardless of delivery proof quality.
Step 1: Identify the exact reason code before touching the evidence file
Visa operates more than 25 reason codes (per Guzco's Visa documentation). Mastercard reason codes relevant to delivery disputes include 4853 (Cardholder Dispute), 4855 (Goods or Services Not Provided), 4837 (No Cardholder Authorization), and 4870 (Chip Liability Shift), among others.
For INR and DNA (Delivery Not Accepted) disputes, the codes you'll encounter most often are:
Visa 13.1: Merchandise Not Received
Visa 10.4: Other Fraud (Card Absent Environment)
Mastercard 4853: Cardholder Dispute (goods not as described or not received)
Mastercard 4855: Goods or Services Not Provided
For authorization disputes, the evidence structure is entirely different and does not require delivery proof at all. Applying a delivery evidence bundle to an authorization reason code is one of the most common representment rejection causes.
Step 2: Build reason-code-specific evidence bundles
For Visa 13.1 / Mastercard 4855 (Merchandise/Goods Not Received):
Evidence field | Status | Notes |
|---|---|---|
Proof of delivery to transaction address | Required | Carrier-confirmed delivery scan with date |
Tracking number matching the transaction | Required | Same carrier record tied to the specific order |
Full recipient name at delivery | Required | Must match cardholder name on the transaction |
Shipping address match (issuer billing address vs. delivery) | Required | Address field-for-field match |
Signature (if high-value or required by issuer) | Conditional | Apply signature confirmation proactively for large orders |
Rebuttal letter addressing the specific reason code | Required | One-page document explicitly addressing Visa 13.1 or MC 4855 |
Order and transaction record | Required | Invoice, order confirmation, and payment transaction details |
Communication log | Recommended | Shows customer acknowledged the order and/or was contacted |
For Visa 10.4 / Mastercard 4837 (Authorization dispute):
Delivery evidence is not the primary rebuttal. Required evidence shifts to:
AVS/CVV match confirmation at checkout
Device fingerprint and IP geolocation data at time of order
Customer account history showing prior purchases and recognizable patterns
3DS authentication confirmation if SCA was applied
Step 3: Track the representment cycle
Card network chargebacks move through up to four stages: first chargeback, second presentment (representment), pre-arbitration, and arbitration. Each stage carries its own deadline and evidence scope.
For Visa representments, the response window is 30 days (per Guzco's Visa documentation). For Mastercard, the representment window runs to 45 days from the chargeback date. Missing either window forfeits the dispute automatically, regardless of how strong the evidence is.
Set internal cutoffs at least 5-7 business days before the provider deadline to account for evidence assembly time and submission confirmation. Guzco's chargeback automation approach files within the 30-day Visa response window on every case, with zero missed deadlines across the portfolio. For teams managing high dispute volumes manually, that buffer disappears fast.
Monitoring thresholds to track: Visa's Dispute Monitoring Program (VDMP) flags merchants at 75 chargebacks and 0.65% dispute rate. Mastercard runs its own Excessive Chargeback Program with similar thresholds. Breaching these programs triggers remediation requirements and fee escalations, so real-time fraud risk scoring per order becomes a structural control, not an optional add-on.
Annotated example evidence package: Visa 13.1 / Merchandise Not Received
File naming convention: [ChargebackID]_VISA_131_[YYYY-MM-DD]
Submission timelines, deadlines, and rejection triggers across providers
The table below shows the intake-to-submission model for each provider. Times are counted from dispute receipt.
Provider | Inquiry response window | Representment/claim deadline | Internal cutoff target |
|---|---|---|---|
Klarna (INR) | Per case notification | Per Klarna case deadline | File at least 11 hours before deadline |
Klarna (Significant Deviation) | 21 days from first contact | Day 21 | Target resolution by Day 11 |
PayPal | 10 days to respond to inquiry | 20 days before buyer can escalate | Respond within 48-72 hours of intake |
Visa | n/a | 30-day representment window | Internal cutoff: 5-7 business days before deadline |
Mastercard | n/a | 45-day representment window | Internal cutoff: 5-7 business days before deadline |
Cross-provider rejection triggers:
Missing required evidence fields for the specific dispute type or reason code
Shipping address on evidence does not match the checkout or transaction address exactly
Signature confirmation absent on orders exceeding the provider's high-value threshold
Evidence not submitted as an accepted file type (attached PDF/JPG, not inline text)
Rebuttal letter absent or does not reference the active reason code
Response submitted after the deadline (automatic loss, no appeal at most stages)
Operational controls to build:
Webhook or API-based dispute intake that timestamps receipt and triggers an internal SLA clock
Evidence completeness scoring before submission (check all required fields against the reason code)
Address match validation against the original checkout record before any evidence bundle goes out
Automated carrier data extraction so tracking and POD fields populate without manual lookup
For teams at scale, maintaining these controls manually across Klarna, PayPal, Visa, and Mastercard simultaneously is where the process breaks down. Guzco's end-to-end claims processing pipeline handles intake, evidence assembly, completeness validation, and provider-format submission automatically, building dispute cases in under 2 minutes with zero missed deadlines across the portfolio. Merchants using it report moving from a 20% win rate to 90%+ without building a dedicated fraud team.
Master evidence index and quick-reference checklist
Use this as a pre-submission validation checklist. Do not submit any package until every Required item for the relevant provider and dispute type is confirmed present.
Quick dispute selector
If INR / DNA (Item Not Received / Delivery Not Accepted): use the delivery proof bundle
If SNAD / Significant Deviation / Faulty Goods: use the deviation bundle
If Authorization dispute (Visa 10.4 / MC 4837): use the authorization rebuttal bundle (no delivery evidence)
Master evidence index template
Create one index sheet per dispute. Fields:
File naming convention
Use the following format across all providers to reduce upload errors and make document review faster for provider reviewers:
[SequenceNumber]_[DocumentType].[extension]
Examples: 01_evidence-index.pdf, 03_delivery-confirmation.pdf, 07_signature-capture.pdf
Keep file names short, descriptive, and free of special characters. Upload in sequence order.
What you've built and where to go next
By following these playbooks, you've established a repeatable, provider-anchored dispute response process. For each incoming claim, you now have:
A classification step that determines which evidence bundle to assemble
A required-field checklist per provider and dispute type
A deadline timeline with internal cutoffs built in
A pre-submission validation gate that catches rejection triggers before they cost you the case
A standardized file structure that reduces human error during upload
The next step is operationalizing the intake step. The playbooks here assume evidence already exists in your carrier and OMS systems. If carrier data isn't flowing into your dispute workflow automatically, that's the integration to prioritize: manual evidence lookup is the bottleneck that causes missed deadlines at volume.
For teams processing a significant number of disputes across multiple providers, consider whether the manual assembly process is the right long-term model. Common retail fraud patterns and INR dispute mechanics are worth reviewing alongside these playbooks to build a broader picture of where your exposure sits. Teams looking to automate the entire pipeline, from dispute intake through provider-format submission and outcome tracking, can explore how Guzco structures that process at guzco.ai.
GUZCO
Keizersgacht 264
1016EV Amsterdam
As featured in
© 2026 Guzco AI. All rights reserved.