Chargeback and Fraud Pattern Review - E-commerce
Use this skill when
Disputes are growing, or fraud controls are costing more in lost good orders than they save.
Common requests:
- "Our chargeback rate is climbing."
- "The processor sent us a warning."
- "Are we declining real customers?"
- "How much of this is friendly fraud?"
Required input
Minimum useful input:
- Dispute export: date, amount, reason code, product, outcome.
- Order volume for the same period so a rate can be computed.
- Current fraud rules or risk tool settings.
Recommended additional input:
- Declined order export.
- Delivery performance and tracking evidence practice.
- Descriptor shown on the customer's bank statement.
- Support tickets preceding disputes.
- Subscription billing setup if recurring.
- Representment win rate and evidence currently submitted.
Before analysis
- Compute the dispute rate against the correct denominator: transactions in the period the dispute relates to, not the period it was filed in.
- Split disputes by reason code family before interpreting anything: true fraud, product not received, product not as described, subscription or recurring, duplicate or processing error.
- Confirm the store's exposure threshold with its provider, since programme thresholds are provider-specific and change.
- Ask what the bank statement descriptor says. Unrecognised descriptors generate disputes that look exactly like fraud.
Analysis workflow
- Get the denominator right before anything else, with
../scripts/dispute_rate.py. A dispute filed in March belongs to the sale that happened in January, so dividing this month's disputes by this month's orders understates a rising problem. The script dates disputes by transaction where the export allows it, says so loudly when it cannot, clusters reason codes into families, and leaves anything it cannot classify visible instead of forcing it. Pass order volume with --orders-per-month; without it you get counts, and a count is not a rate.
- Trend the dispute rate over time and against order volume, and mark any policy, product, or campaign change that lines up with an inflection.
- Cluster disputes by product, channel, geography, order value band, and payment method.
- Separate the three real causes and size each: genuine fraud, service failure dressed as fraud, and friendly fraud.
- For service failures, trace back to the operational cause: delivery delays, missing tracking, unclear delivery promise, or a returns process so slow that customers dispute instead.
- For recurring billing, check notice before charge, descriptor clarity, and cancellation friction. Hard-to-cancel subscriptions convert into disputes.
- Review the fraud rules for over-blocking: what share of declines look like good customers, and what that costs against the fraud actually prevented.
- Review representment evidence quality and win rate by reason code, and identify which evidence is missing at the point of capture rather than at the point of dispute.
Decision and evidence standard
Tag every finding with evidence: chargeback_export, export, payout_report, support_ticket, policy, screenshot, hypothesis, or needs_data. Full vocabulary: ../references/output-standard.md.
Rank findings by disputed value plus the fee exposure behind it, not by dispute count.
Reason codes describe what the customer claimed, not what happened. Treat them as classification, not as truth, and say so.
Output format
Dispute verdict
Dominant cause, current rate, direction, and confidence.
Dispute breakdown
| Reason family |
Count |
Share |
Value |
Likely real cause |
Evidence |
Store-side causes
Operational and policy issues generating disputes, ranked by volume.
Over-blocking check
What good traffic the current rules likely reject, and the cost basis for that estimate.
Prevention queue
| Fix |
Cause addressed |
Effort |
Measurement |
Owner decision |
Missing data
The declined-order export is the missing half of this picture. Disputes show what got through and went wrong; declines show what the rules rejected. Sizing over-blocking without them is guesswork, and it is the finding owners most want.
Example input and output
Input:
- dispute export, 12 months
- order volume by month
- fraud rule settings
- support tickets tagged delivery and billing
Good output excerpt:
| Finding |
Evidence |
Severity |
Confidence |
Business impact |
Effort |
Owner decision |
| Product-not-received disputes cluster on one shipping method with no tracking evidence captured |
chargeback_export, export |
high |
medium |
risk/margin |
S |
do_now |
| Statement descriptor shows the legal entity name, not the brand, across all recurring charges |
payout_report, policy |
medium |
high |
risk/support_load |
XS |
do_now |
What not to do yet: tighten fraud rules across the board when most disputes are service failures, since that removes good orders without touching the cause.
Guardrails
- Do not treat reason codes as proof of what happened.
- Do not recommend tightening fraud rules without estimating the cost of rejected good orders.
- Do not give legal, compliance, or card-scheme advice. Route those questions to the provider or counsel.
- Do not tighten a live risk rule. Rejected orders leave no trace an owner will ever review, so this is the one change in the pack whose damage is invisible after the fact.
- Do not name or profile individual customers as fraudulent in the output.
1---2name: chargeback-fraud-pattern-review-ecommerce3description: Reviews chargebacks, disputes, and fraud declines to separate genuine fraud from service failures and friendly fraud, and to find the store-side causes behind them. Use when dispute rates are rising, a payment provider has raised a warning, or legitimate orders are being declined.4---56# Chargeback and Fraud Pattern Review - E-commerce78## Use this skill when910Disputes are growing, or fraud controls are costing more in lost good orders than they save.1112Common requests:1314- "Our chargeback rate is climbing."15- "The processor sent us a warning."16- "Are we declining real customers?"17- "How much of this is friendly fraud?"1819## Required input2021Minimum useful input:2223- Dispute export: date, amount, reason code, product, outcome.24- Order volume for the same period so a rate can be computed.25- Current fraud rules or risk tool settings.2627Recommended additional input:2829- Declined order export.30- Delivery performance and tracking evidence practice.31- Descriptor shown on the customer's bank statement.32- Support tickets preceding disputes.33- Subscription billing setup if recurring.34- Representment win rate and evidence currently submitted.3536## Before analysis37381. Compute the dispute rate against the correct denominator: transactions in the period the dispute relates to, not the period it was filed in.392. Split disputes by reason code family before interpreting anything: true fraud, product not received, product not as described, subscription or recurring, duplicate or processing error.403. Confirm the store's exposure threshold with its provider, since programme thresholds are provider-specific and change.414. Ask what the bank statement descriptor says. Unrecognised descriptors generate disputes that look exactly like fraud.4243## Analysis workflow44450. **Get the denominator right before anything else, with `../scripts/dispute_rate.py`.** A dispute filed in March belongs to the sale that happened in January, so dividing this month's disputes by this month's orders understates a rising problem. The script dates disputes by transaction where the export allows it, says so loudly when it cannot, clusters reason codes into families, and leaves anything it cannot classify visible instead of forcing it. Pass order volume with `--orders-per-month`; without it you get counts, and a count is not a rate.461. Trend the dispute rate over time and against order volume, and mark any policy, product, or campaign change that lines up with an inflection.472. Cluster disputes by product, channel, geography, order value band, and payment method.483. Separate the three real causes and size each: genuine fraud, service failure dressed as fraud, and friendly fraud.494. For service failures, trace back to the operational cause: delivery delays, missing tracking, unclear delivery promise, or a returns process so slow that customers dispute instead.505. For recurring billing, check notice before charge, descriptor clarity, and cancellation friction. Hard-to-cancel subscriptions convert into disputes.516. Review the fraud rules for over-blocking: what share of declines look like good customers, and what that costs against the fraud actually prevented.527. Review representment evidence quality and win rate by reason code, and identify which evidence is missing at the point of capture rather than at the point of dispute.5354## Decision and evidence standard5556Tag every finding with evidence: `chargeback_export`, `export`, `payout_report`, `support_ticket`, `policy`, `screenshot`, `hypothesis`, or `needs_data`. Full vocabulary: `../references/output-standard.md`.5758Rank findings by disputed value plus the fee exposure behind it, not by dispute count.5960Reason codes describe what the customer claimed, not what happened. Treat them as classification, not as truth, and say so.6162## Output format6364### Dispute verdict6566Dominant cause, current rate, direction, and confidence.6768### Dispute breakdown6970| Reason family | Count | Share | Value | Likely real cause | Evidence |71|---|---|---|---|---|---|7273### Store-side causes7475Operational and policy issues generating disputes, ranked by volume.7677### Over-blocking check7879What good traffic the current rules likely reject, and the cost basis for that estimate.8081### Prevention queue8283| Fix | Cause addressed | Effort | Measurement | Owner decision |84|---|---|---|---|---|8586### Missing data8788The declined-order export is the missing half of this picture. Disputes show what got through and went wrong; declines show what the rules rejected. Sizing over-blocking without them is guesswork, and it is the finding owners most want.8990## Example input and output9192Input:9394- dispute export, 12 months95- order volume by month96- fraud rule settings97- support tickets tagged delivery and billing9899Good output excerpt:100101| Finding | Evidence | Severity | Confidence | Business impact | Effort | Owner decision |102|---|---|---|---|---|---|---|103| Product-not-received disputes cluster on one shipping method with no tracking evidence captured | `chargeback_export`, `export` | high | medium | risk/margin | S | do_now |104| Statement descriptor shows the legal entity name, not the brand, across all recurring charges | `payout_report`, `policy` | medium | high | risk/support_load | XS | do_now |105106What not to do yet: tighten fraud rules across the board when most disputes are service failures, since that removes good orders without touching the cause.107108## Guardrails109110- Do not treat reason codes as proof of what happened.111- Do not recommend tightening fraud rules without estimating the cost of rejected good orders.112- Do not give legal, compliance, or card-scheme advice. Route those questions to the provider or counsel.113- Do not tighten a live risk rule. Rejected orders leave no trace an owner will ever review, so this is the one change in the pack whose damage is invisible after the fact.114- Do not name or profile individual customers as fraudulent in the output.
mardab96