Mastercard 4837 Friendly Fraud: Evidence That Wins

Who This Is For

This guide is for online merchants, fraud teams, and payments operations staff who are responding to Mastercard chargebacks coded Mastercard reason code 4837 — No Cardholder Authorization. If you sell physical goods, digital goods, subscriptions, or services and you receive a claim saying the cardholder didn’t authorize the transaction, this walkthrough shows what evidence to gather, how to structure your response, and which narrative sections Mastercard expects.

It’s particularly useful for merchants using self-service chargeback platforms, PSPs, or in-house chargeback teams who need a repeatable template or process for friendly fraud disputes. If you use automation solutions, review the ecommerce chargeback solution page to see how to integrate evidence collection into order flows.

What This Dispute Means

Mastercard reason code 4837 is raised when the cardholder or issuer alleges the transaction was not authorized by the cardholder. In plain English: someone says they did not give permission for the charge. That can be a true fraud case (stolen card), a charge the customer claims they don’t recognize, or a friendly fraud dispute where a buyer now denies having authorized the purchase.

Under Mastercard’s requirements for code 4837 you must demonstrate merchant-side authorization and, when relevant, that the purchaser received or used the goods or services. The network requires a focused response with specific fields and exhibits. For full code-level requirements, consult the official Mastercard reason code documentation at Mastercard reason code 4837.

Evidence Checklist

• Required fields (include exactly):
  • merchantName — your legal trading name as on the transaction
  • orderId — the merchant order or invoice ID tied to the transaction
  • orderDate — date/time of the purchase (ISO preferred)
  • customerName — name provided on the order and in your records
  • ipAddress — the purchaser’s IP address captured at checkout
• Required exhibit: proofOfDelivery — delivery confirmation showing address, delivery date/time, recipient name/signature, or electronic delivery logs for digital goods.
• Transaction logs: full checkout logs, payment gateway responses (AVS, CVC checks), 3DS authentication data if used, and authorization code.
• Device and behavior signals: device fingerprinting, user agent strings, and session timestamps showing actions like adding to cart, checkout attempts, and account login.
• IP forensic evidence: reverse-DNS, geolocation, time zone correlation, and whether the IP matches shipping/billing address region or past authenticated sessions.
• Proof of use: download logs, login timestamps, subscription usage, or in-app activity showing the cardholder or the account used the product or service.
• Customer communications: emails, SMS, chat transcripts, order confirmations, refund policy acceptance, and any post-sale correspondence.
• Shipping and fulfillment: carrier tracking records, signature capture images, delivery photos, or chain-of-custody notes.
• Policy references: clear copies or links to your terms of sale, refund policy, and authorization policy showing what the buyer agreed to at purchase.
• Additional supporting files: screenshots, timestamped logs, and a concise narrative tying these pieces together into the required narrative sections (transactionOverview, riskSignals, delivery, policies).

Step-by-Step to Win

1. Pull the chargeback and transaction record
   1. Export the gateway/processor transaction report for the orderId.
   2. Capture the original authorization response, AVS, and CVC indicators.
   3. Note the timestamp and any 3DS/issuer authentication payloads.
2. Collect the required fields and exhibits
   1. Confirm merchantName, orderId, orderDate, and customerName match exactly across systems.
   2. Extract the checkout ipAddress and include related IP evidence (geolocation, ISP).
   3. Attach the proofOfDelivery exhibit from the carrier or digital delivery logs.
3. Assemble session and device signals
   1. Pull the session timeline—timestamps for page views, cart additions, and final checkout.
   2. Include device fingerprinting, user agent, and whether the session used a returning-account cookie.
4. Show proof of receipt or usage
   1. For physical goods, include signed POD, delivery GPS/photo evidence, and carrier tracking with timestamps.
   2. For digital goods, include login/download timestamps, IP matches, and activity logs proving consumption.
5. Compile customer communications and policies
   1. Export the order confirmation email, any pre-sale chat, and post-sale messages.
   2. Highlight where the customer accepted terms, and include the specific refund/authorization policy text.
6. Write the narrative using Mastercard sections
   1. Create a short transactionOverview that summarizes the sale, payment authorization, and what was delivered.
   2. Under riskSignals, list IP/device matches, 3DS results, and behavioral indicators that point to legitimate authorization.
   3. In delivery, attach POD and fulfillment evidence and describe carrier tracking/timestamps.
   4. Under policies, reference the exact clause the customer agreed to and how the order complied.
7. Format exhibits and name files clearly
   1. Use a consistent file naming convention: orderId_documentType_date (e.g., 12345_POD_2025-10-01.pdf).
   2. Include an index file that lists each exhibit and a one-line explanation for its relevance.
8. Submit before the 30-day cutoff and follow processor channels
   1. Verify the network cutoff — Mastercard’s code 4837 requires response within 30 days from chargeback receipt.
   2. Submit via your processor’s dispute portal and confirm receipt; keep a timestamped proof of submission.
9. Plan a post-submission follow-up
   1. Track the dispute in your case management system and be ready to provide clarifications.
   2. If the issuer asks for supplemental evidence, prioritize the most direct proof (POD, IP logs, customer acknowledgements).

Common Mistakes

• Failing to include the exact required fields (merchantName, orderId, orderDate, customerName, ipAddress). Missing or mismatched fields are a frequent automatic loss trigger.
• Uploading low-quality or partial proofOfDelivery (e.g., carrier tracking without signature or delivery timestamp).
• Submitting a long, unfocused packet of documents without a clear narrative—adjudicators need a concise story that maps exhibits to the claim.
• Relying only on a refund or internal notes; you must show logs and externally verifiable evidence like carrier data or authentication tokens.
• Including inconsistent customer names or addresses across exhibits; inconsistencies raise credibility issues.
• Ignoring device/IP evidence—many modern disputes hinge on tying the transaction to a device or IP the cardholder used.
• Missing the 30-day Mastercard cutoff for reason code 4837 or delaying submission while hunting for non-essential proof.
• Not redacting PII properly or including irrelevant financial details that complicate the packet—keep it focused and compliant.

Example Narrative Outline

Below is a reusable rebuttal structure merchants can adapt. Use short paragraphs and point to exhibits by file name. Include the required narrative sections exactly as Mastercard expects.

1. transactionOverview

   One-sentence summary: Order orderId placed on orderDate by customerName for item/service. Payment authorized with gateway auth code XXXXXX. Exhibit 1: orderId_transaction_log.pdf.

2. riskSignals

   List concrete signals: checkout IP ipAddress (Exhibit 2: orderId_ip_lookup.pdf); device fingerprint match to prior authenticated session (Exhibit 3: orderId_device_fingerprint.json); 3DS authentication result (Exhibit 4: orderId_3ds_payload.pdf).

3. delivery

   Provide fulfillment proof: carrier delivered on DATE at TIME to recipient NAME with signature/photo. Exhibit 5: orderId_POD_YYYY-MM-DD.pdf. For digital: include download/use logs (Exhibit 6: orderId_download_log.csv).

4. policies

   Quote the exact clauses the cardholder agreed to at checkout, such as authorization to charge, refund policy, and digital delivery consent. Exhibit 7: orderId_terms_accepted.png.

5. closing statement

   Concise summary tying exhibits to the conclusion that the transaction was authorized and fulfilled by the merchant. Request case closure in favor of the merchant.

Processor/Platform/Industry Specifics

Mastercard 4837 responses should be tightly aligned with the network’s required fields and narrative sections. Reference the official card network page at Mastercard reason code 4837 for exact wording and to ensure you include the mandated proofOfDelivery exhibit.

Platform-specific notes:

• Payment gateways: Export your full auth and settlement records. If your gateway provides a native "chargeback response" area, populate it with the required fields and upload exhibits in the order referenced in your narrative.
• Marketplaces: Ensure marketplace order records reconcile with the seller’s fulfillment proof. Provide a clear chain of custody showing the marketplace transmitted order details to the seller and the seller provided POD.
• Subscription businesses: Provide account activity logs, billing history, and evidence of delivered digital content or service usage, since these prove the payer had access.
• Digital goods and software: For non-physical deliveries, proofOfDelivery can be satisfied by download logs, IP-based downloads, license activation records, or in-app usage timestamps. Include a clear mapping of account email/ID to the cardholder name where possible.
• POS and card-present channels: While 4837 is more common for card-not-present transactions, if raised, provide terminal logs, EMV/authorization records, and supervisor attestations for keyed or manual transactions.
• Industry best practice: Normalize the evidence into a single PDF index and keep raw logs ready for supplemental requests. Processors and issuers appreciate a single “index” document that points to each exhibit and explains why it matters.

For merchants who want a reference hub of codes, see the broader chargeback reason code hub for other network requirements and how they compare.

How ProofReturn Helps

ProofReturn automates capture, organization, and formatting of the evidence Mastercard requires for code 4837 responses. Using callbacks from your checkout, ProofReturn can collect the mandatory fields (merchantName, orderId, orderDate, customerName, ipAddress), consolidate session/device signals, and attach formatted proofOfDelivery exhibits so your dispute packet is complete and consistent.

Automation reduces manual errors like mismatched field values, missing exhibits, or late submissions. It also creates an index file that maps exhibits to the Mastercard narrative sections (transactionOverview, riskSignals, delivery, policies), helping reviewers quickly understand the case. If you manage many disputes, automating this repetitive work improves response time and ensures the required 30-day deadline for a 4837 response is met more consistently.

FAQ Section

1. What exactly must I include for Mastercard 4837?

Include the required fields: merchantName, orderId, orderDate, customerName, and ipAddress. Attach proofOfDelivery and provide a narrative broken into transactionOverview, riskSignals, delivery, and policies describing how the evidence shows the transaction was authorized and fulfilled.

2. Is proofOfDelivery always a physical signature?

No. proofOfDelivery can be carrier signature for physical goods, delivery photos with GPS/timestamp, or electronic delivery logs for digital items (download timestamps, license activation). The key is that the exhibit must verifiably show the buyer received or accessed the product.

3. How do I show the IP address ties to the cardholder?

Provide the checkout ipAddress captured during the transaction, geolocation lookup results, and any historical account logins from the same IP or device fingerprint. Correlate timestamps to show the same user performed the purchase and subsequent account activity.

4. What if the customer used a different shipping address?

Different shipping addresses are not fatal, but you must explain and provide supporting signals: why the address was used (gift, workplace), matching phone number or email, delivery confirmation showing recipient name, and any prior account relationship that explains the discrepancy.

5. How important is a clear narrative?

Very important. Networks and issuers review many cases; a concise narrative that maps each exhibit to the required narrative sections saves time and improves understanding. Use explicit references to file names and one-line explanations for each exhibit.

6. What timeline should I follow for submission?

Mastercard reason code 4837 requires submission within 30 days of the chargeback. Collect and submit your evidence promptly and confirm processor receipt to ensure the dispute is considered.

7. Can I submit additional evidence after the first packet?

Yes. Issuers sometimes request supplemental evidence. Prioritize the most directly relevant documents (POD, IP logs, authentication records) and respond to follow-up requests quickly. Keep your case organized so you can locate and submit follow-ups fast.

8. Where can I find a template for the Mastercard 4837 response?

Use a template that enforces the required fields and narrative structure. For more detailed examples and process templates, see the official Mastercard reason code 4837 page and the merchant resource guides on the ecommerce chargeback solution page. If you want an expanded playbook, consult our practical guide on chargeback handling in How to Win Chargeback Disputes — 2025 Guide.

9. Do I need to redact customer PII in evidence packets?

Redact sensitive elements not needed for adjudication (like full card numbers), but keep name, address, and order-related data intact. Follow your processor’s privacy guidelines and legal obligations when sharing evidence.

10. What if I can’t produce a signature or POD?

If no signature exists, provide the best available evidence: carrier tracking with delivery status and timestamp, delivery photos, recipient phone confirmation, and strong device/IP signals linking the cardholder to the purchase. Explain clearly why signature is unavailable and why other evidence proves delivery or use.

Related Resources

• Mastercard reason code 4837 — No Cardholder Authorization
• Mastercard reason code 4837 evidence requirements (narrative and exhibit checklist)
• chargeback reason code hub — centralized reference for network rules and required fields
• ecommerce chargeback solution page — productized approaches to evidence collection and automation
• How to Win Chargeback Disputes — 2025 Guide — a broader playbook for dispute strategy
• Visa chargeback response deadlines — 2025 update — for cross-network deadline context
• Stripe chargeback evidence requirements — gateway-specific evidence tips

Final CTA

If you want a formatted, ready-to-submit Mastercard 4837 packet tailored to the required narrative sections and exhibits, generate a compliant response now at /generate. Use the tool to pre-fill the required fields, assemble proofOfDelivery, and create the narrative sections (transactionOverview, riskSignals, delivery, policies) so you can submit within the 30-day window with confidence.