Disputes and fraud

4 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Got a chargeback — how long do I have and what wins?

A dispute (charge.dispute.created webhook) opens when a cardholder contests a charge with their bank; Stripe immediately debits the disputed amount plus a dispute fee (varies by region, roughly $15 in the US as of early 2026 — check current pricing). Response windows are set by the card network and are short — typically about 7–21 days depending on network and reason code; the dispute object's evidence_details.due_by (Unix seconds) is authoritative. Winning evidence for SaaS: proof of account access/usage logs tied to the cardholder, acceptance of your ToS at signup, prior undisputed payments on the same card, AVS/CVC match results, and clear billing descriptor. Submit evidence once — you generally can't amend after submission. Countering fraud-coded disputes for digital goods rarely wins; subscription_canceled-coded ones often do with cancellation logs.

What does Radar actually block, and should I write rules?

Radar is Stripe's ML fraud screening, on by default: it scores each payment and blocks or allows based on risk level you configure (Dashboard → Radar), plus optional custom rules ('block if :card_country: != :ip_country:', 'review if amount > X'). Key facts: a Radar block appears as a failed charge with a fraud-related decline — it is NOT a dispute and costs no dispute fee; 3DS, when completed, shifts fraud liability to the card issuer, which is why high-risk transactions are worth steering to 3DS via Radar rules (request_three_d_secure: any/ automatic). Custom rules beat ML thresholds for SaaS-specific patterns (trial abuse with disposable emails, card testing on your checkout). Watch for card-testing attacks: bursts of small declines — mitigate with rate limiting and CAPTCHA on checkout, Radar alone won't save an exposed endpoint.

Refunds: full, partial, and what happens to fees and subscriptions?

A refund (refund.create on a charge or payment_intent) returns money to the original card; as of early 2026 Stripe generally does NOT return its processing fees on refunds. Partial refunds are supported; multiple partials can't exceed the charge total. Critically, refunding does NOT cancel the subscription — those are independent operations, and 'refunded but still subscribed' (they get billed again next month → dispute) and 'canceled but not refunded' (angry churned customer) are both classic support fires. Decide policy per case and do both actions deliberately. Refunds reduce your next payout via balance transactions, and can take days to weeks to appear on the customer's statement — set expectations in the confirmation email. Excessive refund/dispute ratios put your account at risk of reserves or termination.

Trial abuse and free-tier farming — how do I stop it?

Attackers cycle disposable emails and stolen/disposable cards to harvest trials. Layered defenses that work: require a card for trials (kills most abuse, costs conversion — measure the tradeoff); fingerprint by card, not just email — check Stripe's customer/payment method for duplicate card fingerprints (the card fingerprint field is stable per PAN) and block repeat trials on the same card; use Radar rules to block prepaid cards and mismatched IP/card countries on trial signups; add CAPTCHA/email verification before trial activation; delay full feature access (export limits) until first successful payment. Track your dispute rate — card networks have monitoring programs with thresholds (around ~0.9% historically; verify current Visa/Mastercard program rules) that trigger fines and remediation.

Give your agent this brain