WooCommerce Chargeback Reason Codes Explained (and How to Respond to Each)

A chargeback notification arrives. The processor dashboard shows a reason code alongside the dispute — something like fraudulent or product_not_received. Most store owners glance at it and move straight to the evidence-gathering. That’s a mistake.

The reason code is the most important piece of information in the notification. It tells you what the cardholder is claiming, which standard the card network will apply when reviewing your response, and — critically — what categories of evidence count and what won’t move the needle at all. Submitting irrelevant evidence (however thorough) wastes your evidence slots. Submitting the right evidence, matched to the exact code, is how you build a case that actually wins.

This guide is a reference companion to the broader WooCommerce chargebacks guide and to the tactical response walkthrough. Bookmark this page and return to it when a dispute arrives — look up the reason code, read what it signals, and build your evidence package accordingly.

What a reason code actually is

A reason code is a standardized label assigned by the card network — Visa, Mastercard, American Express, Discover — that categorizes why a cardholder is disputing a charge. Card networks invented these codes to give banks, processors, and merchants a shared vocabulary. Without them, every dispute would need to be adjudicated entirely from scratch; with them, each party knows upfront what rules apply.

The code is assigned by the issuing bank (the bank that issued the cardholder’s card) when the dispute is filed. The bank selects the code from a list defined by the card network based on what the cardholder told them. The code is then passed through the network to your acquiring bank (the bank that processes your payments) and surfaced in your processor dashboard.

Why this matters operationally: the code is not a verified fact about what happened. It reflects what the cardholder told their bank. A customer who received a product perfectly but decided they didn’t want to pay for it can file under “product not as described” even if that’s not true. Your job when contesting a dispute is to provide evidence that contradicts or undermines the code’s implied claim.

Card-network codes vs. Stripe’s reason categories

This is where things get slightly complicated, and it is worth being honest about it.

Each card network maintains its own proprietary set of numeric or alphanumeric reason codes. Visa’s codes, Mastercard’s codes, American Express’s codes, and Discover’s codes are all distinct systems. The specific code numbers and letters change as networks update their programs — and they have changed meaningfully over the past several years as networks have overhauled their dispute frameworks. Publishing specific numeric codes in a blog post carries real risk of being wrong by the time you read it.

Stripe — which is the processor most WooCommerce stores using WooPayments or the Stripe plugin will interact with — translates all of these network-specific codes into a smaller set of human-readable reason categories when displaying disputes in the Dashboard and via the API. These Stripe reason strings are stable across card networks and are the ones you’ll actually see in your dispute notification. They are also the ones that matter operationally, because Stripe’s evidence submission form is organized around them.

This guide is organized by Stripe’s dispute reason categories. For each category, a note explains which underlying network concepts it typically maps to. But treat that mapping as illustrative, not as a definitive lookup table — if you need the precise network code for a specific dispute, check the Stripe Dashboard, where the underlying network code is usually displayed alongside Stripe’s label. Your processor’s dispute detail page is always the authoritative source for any individual case.

Fraudulent — unauthorized transaction

The fraudulent reason is the most frequently seen dispute category across e-commerce. When Stripe surfaces this label, it means the cardholder is claiming they did not authorize the transaction — someone else used their card details to make the purchase without their knowledge.

What it signals

True fraud: the cardholder’s card details were stolen through a data breach, phishing attack, physical theft, or card-skimming device, and a third party used them to buy something from your store. The cardholder is often telling the truth — they genuinely didn’t make the purchase. This is distinct from friendly fraud, where the cardholder did authorize the charge but disputes it anyway. Both can arrive under the same reason code; the code reflects the claim, not the verified reality.

The underlying network codes that typically generate this label in Stripe include fraud-category codes from Visa, Mastercard, American Express, and Discover — but the exact numeric codes vary by network and are subject to change as networks update their frameworks. The relevant behavior the code describes is stable even when the code itself isn’t.

What evidence to submit

For true fraud cases, your defense relies on showing that the real cardholder was the one who made the purchase — or that the order was so thoroughly authenticated that the cardholder’s claim is implausible. The most useful evidence:

• AVS and CVV match confirmation. If the billing address and card security code provided at checkout matched the card on file (and your processor confirms this), include that confirmation. A transaction that passed both checks is harder to claim as unauthorized.
• Delivery to the billing address. If the item was shipped to the same address as the cardholder’s billing address — not a reshipping depot or freight forwarder — that alignment is meaningful. Fraudsters often ship to non-billing addresses to intercept packages before the cardholder notices.
• Prior successful orders from the same card. If this cardholder has purchased from you before with the same card and never disputed those transactions, that history is relevant. Include it.
• IP address and device data matching the cardholder’s known location. If the checkout session IP resolves to the city or region where the cardholder lives, that alignment supports authorization. Some processors accept this technical data as part of the evidence package.
• Customer communication before the dispute. Did the customer email you after the purchase to ask about shipping status, exchange items, or leave a review? That communication shows engagement with the order that contradicts a claim of “I didn’t make this purchase.”
• 3D Secure authentication. If the transaction was authenticated via 3D Secure (Verified by Visa, Mastercard SecureCode, etc.) and the cardholder authenticated successfully, the liability for fraud disputes typically shifts to the card network under their chargeback liability shift rules. Check your processor documentation for the current rules around liability shift — Stripe documents this clearly for transactions processed through its platform.

When to accept rather than fight: if the billing and shipping addresses are entirely different, the order was placed from an unusual IP, and the customer has no prior history with your store, you were probably targeted by a fraudster. Fighting that case is unlikely to succeed, and the evidence isn’t there. Accept the dispute, absorb the loss, and focus on preventing the next one by reviewing your fraud controls.

Unrecognized — cardholder doesn’t remember the charge

The unrecognized reason in Stripe indicates that the cardholder saw a charge on their statement they don’t recognize — they’re not claiming fraud outright, just that they can’t identify what the charge was for. This is softer than a fraud claim and is often resolvable with documentation that clarifies the transaction.

What it signals

Unrecognized disputes frequently arise from descriptor confusion. The name that appears on the cardholder’s bank statement often does not match your store name — it might show your payment processor’s name, your legal business entity name, or a truncated version that doesn’t ring any bells. A customer who bought from “Meadowbrook Artisan Soaps” might see “MBK HOLDINGS LLC” on their statement and file a dispute because they genuinely don’t know what that charge is. Descriptor-related disputes are among the most easily preventable.

They can also reflect legitimate forgetfulness (especially for smaller purchases or purchases made months ago), a family member using a shared card without notifying the cardholder, or a subscription the cardholder forgot they signed up for.

What evidence to submit

• Your store name and what you sell. A clear one-paragraph description of your business that connects your trading name to the charge descriptor the cardholder would have seen.
• Order confirmation email. The email you sent at the time of purchase, addressed to the cardholder’s email, showing what was ordered, the amount, and the date. This is often enough to close an unrecognized dispute — the cardholder sees it, recognizes the purchase, and withdraws the dispute.
• Shipping and delivery confirmation. If the item was delivered, proof of delivery connects the purchase to a physical outcome the cardholder can verify.
• Customer communication history. Any messages between you and the cardholder — order status inquiries, shipping updates, post-delivery follow-ups — that show the cardholder was aware of and engaged with the order.

Unrecognized disputes have among the better win rates for merchants who respond, because the underlying issue is often informational rather than adversarial. Your job is to help the reviewer (and potentially the cardholder) connect the dots between the statement charge and a real purchase they made.

Product not received

The product_not_received reason covers disputes where the cardholder claims the item they ordered never arrived. This is one of the two most common reason categories in e-commerce, and it is one where strong tracking documentation is decisive.

What it signals

The cardholder is saying the order was paid for but never delivered. This can reflect genuine non-delivery (the carrier lost the package, it was stolen from the doorstep, it was returned to sender without notification) or it can reflect friendly fraud (the cardholder received the item but filed anyway to get a free product). The dispute system cannot distinguish between these scenarios on its own — your evidence determines which explanation is more plausible.

What evidence to submit

• Carrier tracking showing delivery. This is the primary piece of evidence. Include the full tracking history — not just the final “delivered” status, but the scan history showing the package moving through the carrier network and arriving at the delivery address. A screenshot or PDF from the carrier’s website carries more weight than a tracking number alone.
• Delivery to the billing address or a confirmed customer address. If the delivery address matches the cardholder’s billing address, note that. If it matches an address the customer provided during checkout, include that too. Delivery to an address the cardholder confirmed is harder to dispute as “never received.”
• Signed proof of delivery. For high-value orders, a signature confirmation from the carrier is one of the strongest possible pieces of evidence. If you required a signature and have it, lead with it.
• Order confirmation and shipping notification emails. Show that you communicated the tracking information to the cardholder so they could monitor delivery. If they had the tracking number and never flagged non-delivery until the dispute, that context is relevant.
• Proof of prior successful deliveries to the same address. If this customer has received multiple orders at the same address without issue, that history makes the “never received” claim less plausible.

When to accept: if you have no tracking, shipped without confirmation, or the carrier’s history shows an unsuccessful delivery attempt with no follow-up, your evidence position is weak. A customer who genuinely didn’t receive an item is owed their money back, and accepting the dispute efficiently may be fairer and less costly than a drawn-out fight.

Product unacceptable — not as described

The product_unacceptable reason covers disputes where the cardholder claims the item they received was significantly different from what was described — wrong item, counterfeit product, materially different condition, or fundamentally broken in a way that wasn’t disclosed. Stripe may also surface this for disputes involving services that were not rendered as agreed.

What it signals

The cardholder is making a quality or accuracy claim: what arrived was not what they paid for. This category covers a wide range — from genuinely wrong items shipped due to warehouse error, to products that arrived damaged, to customers who have buyer’s remorse and are using “not as described” as a mechanism to dispute a purchase they simply regret. The card network review will compare your product listing against the cardholder’s claim.

What evidence to submit

• Your product listing as it appeared at purchase. Screenshots of the product page — description, images, specifications, size/color charts, condition notes — as they existed when the order was placed. If your product page has changed since, be aware that the reviewer is evaluating the claim against what the customer saw, not what the page says today.
• Order details confirming what was purchased and what was shipped. Include the order line items and any picking/packing confirmation that shows the correct item was selected and sent.
• Your return and refund policy. The policy the customer agreed to at checkout matters here, particularly if the customer made no attempt to contact you to resolve the issue before disputing. A “not as described” claim that bypasses your documented return process is a reasonable thing to point out.
• Customer communication showing acceptance or use of the item. Did the customer email you after receiving the package — about anything, including questions about the item — that shows they interacted with it? Messages written after delivery that don’t mention a quality problem undermine the “not as described” claim.
• Photos or documentation of the item shipped. If you have any documentation of what left your warehouse — particularly for custom or high-value items — include it. This is rare for most WooCommerce stores but extremely valuable when it exists.

When to accept: if there was genuinely a fulfillment error — wrong item, seriously damaged goods — the cardholder’s complaint is legitimate. Accepting is the right outcome. Use the case as a trigger to review your picking and packing process. A customer who received the wrong item and had to file a dispute rather than getting a quick replacement from your customer service has already had a poor enough experience; making them wait weeks for a dispute resolution makes it worse.

Subscription canceled

The subscription_canceled reason applies when a cardholder disputes a recurring charge, claiming they had already canceled the subscription before the charge was made — or that they never agreed to a recurring billing arrangement in the first place.

What it signals

Recurring billing disputes are a distinct category because the card networks have specific rules around subscription disclosures, cancellation mechanisms, and billing notification requirements. A merchant who buried renewal terms in fine print, made cancellation difficult, or continued billing after a cancellation request was received is in a weak position regardless of what their terms of service say. Conversely, a merchant who sent renewal reminders, provided a clear self-service cancellation mechanism, and has documented confirmation that no cancellation was received is in a strong position.

For WooCommerce stores running subscription products (via WooCommerce Subscriptions, Stripe’s recurring billing, or similar), this is the category most likely to arise when subscription management is unclear or when customer service is slow to process cancellation requests.

What evidence to submit

• Your subscription terms as presented at sign-up. The exact language the customer agreed to, at the point of purchase, describing the billing frequency, amount, and cancellation process. Card networks expect subscription terms to be clearly disclosed — not buried — at checkout.
• Proof that the customer agreed to recurring billing. Order confirmation showing the subscription terms were accepted. If your checkout required a checkbox or explicit acknowledgment for recurring billing, include evidence of that step.
• Renewal notification emails. If you send renewal reminders before the charge (which Visa, Mastercard, and most card networks now require or strongly recommend for subscription merchants), include those sent emails with delivery timestamps. A reminder that was delivered before the disputed charge supports the position that the cardholder had the opportunity to cancel.
• Your cancellation records. Documentation showing that no cancellation request was received from this customer before the disputed charge. If they requested cancellation after the charge and you’ve since processed it, note that — and consider whether you should issue a proactive refund rather than fighting.
• Access logs or usage data showing the service was used. For digital subscriptions, evidence that the customer accessed the service during the period they’re disputing is meaningful. Login records, download history, or feature-use logs (if available) can contradict a “I already canceled” claim.

When to accept: if you received a cancellation request and failed to act on it before the next billing cycle, the cardholder is right and you should accept, refund, and fix the process. If the cancellation mechanism was unclear or buried, the dispute may be technically valid even if you believe the customer knew what they were signing up for. Poor subscription UX is a business problem before it becomes a dispute problem.

Duplicate charge

The duplicate reason indicates the cardholder believes they were charged more than once for the same transaction. They are saying you billed them twice for a single order or purchase.

What it signals

Duplicate-charge disputes usually arise from one of a few technical situations: a double-click on the checkout button generating two separate orders, a retry mechanism that charged the card twice after a timeout, a subscription system that created a duplicate billing record, or — occasionally — a customer who placed two separate orders intentionally but then disputes one of them as a duplicate when they see two charges side by side.

What evidence to submit

• Proof that the two charges are for distinct orders. If the two charges represent two different orders (different items, different dates, different order IDs) and both were legitimately placed, document each order separately. Show the order confirmation for each, with line items that distinguish them from each other.
• Documentation that any actual duplicate has been refunded. If you already identified and refunded a duplicate charge, include that refund confirmation with timestamps. A proactive refund that the cardholder didn’t notice before filing the dispute can close the case immediately.
• Transaction IDs and payment records showing distinct authorizations. Your payment processor can provide the distinct authorization codes and timestamps for each transaction. These show that each charge was a separate authorization event rather than a system error doubling one.

When to accept: if your system genuinely generated two charges for one order — a technical error — accept the dispute for the duplicate charge, issue a refund for the other if you haven’t already, and investigate what caused the duplication. Retry logic, payment form submit handling, and subscription billing systems are the usual culprits. This is the category where dispute prevention is almost entirely operational.

Credit not processed

The credit_not_processed reason covers disputes where the cardholder says they are owed a refund — because they returned an item, canceled a service, or received an explicit promise of a credit — and the refund never appeared on their statement.

What it signals

The cardholder expected money back. They returned an item following your return policy, or you agreed to refund them, or they canceled within a period that entitled them to a refund — and the credit either was never issued or has not yet cleared. This is one of the most avoidable dispute categories because the dispute is essentially a failure of customer service communication: the customer knew (or thought they knew) a refund was coming, it didn’t arrive, and they went to their bank instead of following up with you.

Bank statement processing times can compound this. A refund issued on Friday may not appear on the cardholder’s statement for several business days, particularly if their bank’s clearing cycle adds delay. Customers who aren’t told to expect processing time sometimes file disputes for refunds that are already in transit.

What evidence to submit

• Proof of the refund issuance. If you already processed the refund — before or after the dispute — include the refund confirmation from your processor with the transaction ID and timestamp. A completed refund that the dispute review can verify is the cleanest possible defense.
• Your return and refund policy. If the customer is claiming a refund they are not entitled to under your policy (they returned outside the return window, the item was non-returnable, the condition didn’t meet your return criteria), include the policy as published at the time of purchase.
• Communication about the refund timeline. If you told the customer the refund was processing and gave an expected clearing date, include that communication. A customer who filed a dispute three days after being told “please allow 5–7 business days” is a very different case from one who filed after receiving no communication for weeks.
• Proof that the return was not made. If the customer claims to have returned an item you never received, document that the item hasn’t been received in your warehouse. Carriers’ inbound tracking records can confirm whether a return shipment was delivered to you.

When to accept: if you owe the refund, issue it immediately (if you haven’t) and accept the dispute. Fighting a valid refund request through the dispute process is both unlikely to succeed and damaging to your relationship with the customer and your processor. The honest move here is also the practical one.

General — everything else

The general reason is Stripe’s catch-all for disputes that don’t fit clearly into the more specific categories above. It may also appear when the underlying card-network code doesn’t map cleanly to any of Stripe’s defined labels, or when the dispute involves a more complex set of facts that the card network has classified under a broadly defined code.

What it signals

General disputes are harder to prepare for precisely because the reason is ambiguous. The cardholder has filed some kind of dispute, but the category doesn’t tell you clearly whether it’s about delivery, product quality, authorization, or billing. Your first step with a general dispute is to read the dispute details carefully in your processor dashboard — Stripe typically surfaces the cardholder’s stated reason in the dispute details even when the code itself is generic. Build your evidence response around the underlying claim, not the label.

What evidence to submit

For general disputes, assemble a broad but coherent package that addresses the most plausible interpretations of the claim:

• Order confirmation and invoice
• Delivery confirmation and tracking
• Product description and any relevant photos
• Customer communication history
• Your refund and return policy
• Any other documentation specific to what the dispute details describe

The rebuttal narrative matters more in general disputes than in specific ones, because you’re doing more work to frame what the dispute actually is and why you should win. Write a clear, factual explanation of what happened — the order, the fulfillment, the customer interaction — and let the documentation support each claim in the narrative.

Quick-reference table

Evidence that rarely helps

There are a few types of evidence that merchants commonly submit because they feel relevant but rarely move a dispute reviewer. Knowing what to leave out keeps your package focused on what actually matters.

• Your internal WooCommerce order notes. Notes you’ve added to your own order screen — “confirmed shipped,” “customer seemed happy” — are written by you and carry no independent weight. Reviewers need evidence from sources outside your control (carriers, email threads, payment records).
• Screenshots of your own order dashboard showing “Completed.” An order marked complete in WooCommerce confirms you processed the order. It says nothing about delivery or customer satisfaction. It’s background context at best, not evidence.
• Your return policy alone, with no supporting context. Pointing to “all sales final” or a strict return window is not a defense against a fraud claim or a genuinely defective product. Policy is relevant as one layer of context but will not override a clear customer-protection right on its own.
• A description of how well your business usually operates. “We have a 4.8-star rating and have processed 3,000 orders” is not responsive to the specific dispute claim. Reviewers evaluate the transaction in front of them, not your general reputation.
• Anything that argues the customer is lying. Dispute review is not a court, and accusations don’t help. Present facts that contradict the claim — an email the customer wrote, a delivery scan, an authentication log — rather than characterizing the customer’s motives.

Tracking reason codes over time

The real value of reason codes is not just in responding to individual disputes — it’s in the pattern they reveal across your dispute history. If a third of your disputes are arriving as product_not_received and you’re shipping without tracking, that’s a structural problem, not a dispute-by-dispute response problem. If you’re seeing a run of subscription_canceled disputes, something in your renewal and cancellation flow needs fixing.

Most WooCommerce stores don’t look at this data systematically because it’s spread across individual notifications that arrive in email and live in the processor dashboard without being aggregated anywhere useful. For stores using Stripe or WooPayments, TrustLens captures dispute records per customer and feeds them into the Chargeback Ratio Speedometer on the dashboard — giving you a running view of your blended dispute rate and which customers account for repeat disputes.

The TrustLens Chargeback Monitor (Pro) adds the open disputes worklist with deadline countdowns so nothing slips past the response window, and the per-brand ratio breakdown that tells you whether you’re approaching Visa, Mastercard, Amex, or Discover monitoring program thresholds. But even the free chargeback tracking in TrustLens makes it meaningfully easier to notice when a specific reason code is becoming a pattern rather than a one-off.

Once you can see the pattern, you can fix the upstream cause rather than responding to each dispute in isolation. That’s where the real reduction in dispute volume comes from — not from getting better at submitting evidence, but from eliminating the conditions that generate disputes in the first place.

Common questions

Can a dispute arrive under the wrong reason code?

Yes. The issuing bank assigns the code based on what the cardholder told them, and the bank is not verifying the claim before assigning the code. A customer who received an item but wants their money back might say “I didn’t authorize this” to their bank, generating a fraudulent code, even though the real situation is closer to product_unacceptable or buyer’s remorse. Your evidence should address what actually happened, while still engaging with the code’s formal claim. If your evidence contradicts the code’s implied claim — showing, for example, that the cardholder was authenticated and received the item — that contradiction is your case.

What’s the difference between Stripe’s reason labels and the actual card-network codes?

Stripe translates each card network’s proprietary dispute codes (Visa’s numeric codes, Mastercard’s alphanumeric codes, and so on) into a smaller set of English reason strings for display in the Dashboard and API. The underlying network code is usually visible in the dispute details view as well. For most WooCommerce store owners, Stripe’s reason strings are the ones that matter operationally — they determine how Stripe’s evidence submission form is organized and what evidence types Stripe will accept and forward. If you need the raw network code for a specific dispute (for example, for a third-party dispute management tool), it’s in the dispute detail view in the Stripe Dashboard.

Does every dispute code require the same evidence?

No — and this is the central point of this guide. The reason code determines the implied claim, the evidence standard the card network applies, and which pieces of documentation are relevant. Delivery confirmation is essential for product_not_received and helpful for fraudulent, but does almost nothing for subscription_canceled or credit_not_processed. Tailoring your evidence package to the specific code is what separates a focused, winnable response from a generic evidence dump that reviewers discount.

How long do I have to respond to a dispute?

Response windows vary by processor and card network, but for most Stripe disputes, the window is around seven days from the dispute creation date. WooPayments typically uses a similar window. Check the exact deadline in your processor dashboard for each dispute — it is printed clearly in the dispute detail. Do not assume a standard window; missing the deadline by even one day results in an automatic loss regardless of evidence quality. For a deeper walkthrough of the submission process, see the evidence package and rebuttal guide.

What is a “pre-arbitration” and when does it happen?

After the first dispute ruling, either party — merchant or cardholder’s bank — can sometimes escalate to a second review called pre-arbitration or arbitration, depending on the card network. This extends the timeline significantly, adds fees (which can exceed the disputed amount on smaller transactions), and is generally only worth pursuing for high-value disputes where you have strong evidence and the original ruling appears to have overlooked it. Most disputes are resolved at the first ruling stage, and most merchants should not escalate to arbitration unless the amount and evidence quality both justify it.

Should I always fight a dispute?

No. Fighting every dispute is a misallocation of time and evidence slots. The decision to fight or accept should be based on: whether you have evidence that addresses the specific code’s claim, whether the disputed amount exceeds the time cost of preparing a response, and whether the cardholder’s underlying claim is legitimate. For true fraud, defective products, and fulfilled cancellations, accepting is often both the right and the practical choice. For friendly fraud with strong delivery and authorization evidence, fighting makes sense. The broader guide to WooCommerce chargebacks and disputes covers the fight-or-accept decision in more depth.