3 Stripe mistakes that almost got my account banned

My Stripe account almost got banned launching my first app. I wasn't doing fraud or selling anything sketchy. It was three niche things nobody puts in the vibe coding tutorial, because the tutorial ends the moment the checkout button works.

Building the app with Claude legit takes an afternoon. Getting the payments right the first time is what keeps your payouts moving. The three mistakes first, then the checklist.

1. Missing policy requirements

Stripe crawls your live site before payouts fully activate and checks that the pages a card issuer expects are actually there. If they aren't, payouts stay paused while you fix them, and the email telling you why lands after your first customers have already paid.

What it's looking for:

• Refund terms. What gets refunded, within how many days, and how to ask.
• Cancellation rules. How a subscriber cancels, when it takes effect, and whether they're billed for the current period.
• Customer service contact. An email or a form a customer can find without logging in.
• A plain description of what you sell, with pricing and currency, that matches what Stripe Checkout charges.
• A privacy policy and terms of service, linked from the footer, not buried three taps inside the app.

Fix: a /legal route with those pages, linked from the footer of the marketing site, live before you submit for activation. Put the same URLs in the Stripe dashboard under your business details so the reviewer lands on them. Twenty minutes with Claude, and it's the cheapest twenty minutes in this post.

2. Low-volume dispute spikes

Dispute rate is chargebacks divided by transactions. Big companies have the denominator on their side. You don't.

At 200 transactions a month, two chargebacks puts you at 1%. Stripe's line is 0.75%, and above it your account goes into review. Two chargebacks, not two hundred, and you're in the shit.

Where the two come from in an AI app specifically: surprise overages and confusing billing descriptors. Someone burned through tokens they didn't know were metered, or they see MURPHLABS LLC on a bank statement and don't recognise it, and the fastest button in their banking app is Dispute.

Fix:

• Statement descriptor is the name of the product, the one on the receipt and the login screen, not your LLC.
• Anything metered gets a hard cap the user sets and an email at 80% of it, so nobody ever gets a silent overage.
• Refund first, argue later. A refund costs you the sale. A dispute costs you the sale, a $15 fee, and a point on the one number that decides whether Stripe keeps you.
• Turn on Stripe receipts with your support email on them, so the first click is your inbox, not the bank's.
• Radar on before launch, and a weekly look at the disputes tab for early fraud warnings. A warning you refund in time never becomes a chargeback.

The third one is the one people skip, and it's the only thing you get to say when a dispute lands.

3. Weak terms of service

You already carry full chargeback liability on every transaction. When a customer disputes, the card issuer decides, and you get one shot at submitting evidence. Clear usage terms and token limits are the strongest evidence you can send.

"By clicking Pay you agree to our terms" pointing at a terms page the AI generated from a template is not evidence. It says nothing about your product, so it proves nothing about what the customer agreed to.

What your terms need to say, specifically:

• What the customer gets, in units. Messages, generations, tokens, seats, per month.
• What happens at the limit. It stops, or it bills, and at what rate.
• That it's a digital service delivered instantly, so refunds are available for X days or on Y conditions, and not otherwise.
• How to cancel, and that cancelling stops the next charge, not the current one.
• That they accepted these terms at checkout. A checkbox you log with a timestamp and a user id.

Fix: write the terms about your actual product. Log acceptance. When a dispute lands, send the terms, the acceptance record, the usage log, and the support thread, because that packet is what wins.

The pre-launch checklist

This is what the DM sends. Run it the week before you flip test mode off.

1. 1.Refund policy page is live, linked in the footer, with a number of days in it.
2. 2.Cancellation policy page is live and says when a cancellation takes effect.
3. 3.Support email or form is reachable without logging in, and a human reads it within 24 hours.
4. 4.Privacy policy and terms of service are live and linked on the checkout page.
5. 5.Pricing on the site matches what Checkout charges, in the same currency.
6. 6.Business details, support email and website URL on the Stripe dashboard match the live site.
7. 7.Statement descriptor is the product name, 22 characters or fewer, and it's what shows on the receipt.
8. 8.Terms name the units you sell, the limit, and what happens at the limit.
9. 9.Terms acceptance is logged: checkbox, timestamp, user id.
10. 10.Usage caps and the 80% alert email are wired up for anything metered.
11. 11.Stripe receipts are on, with the support email in them.
12. 12.Webhook signature is verified before you touch the payload, and the test key can't reach production.
13. 13.Refund flow tested end to end: one real charge on a real card, one real refund.
14. 14.Radar is on, and there's a weekly calendar reminder to check disputes and early fraud warnings.

The prompt

Paste this into Claude Code from the root of your project. It checks what it can see in the code and tells you what's missing from the list above.

Audit this project against a Stripe pre-launch checklist and report findings with file and line.

Check for:
1. Public routes for a refund policy, cancellation policy, privacy policy, terms of service, and a customer support contact. Confirm each is linked from the site footer and from the checkout page.
2. Stripe Checkout or PaymentIntent config: the statement_descriptor or product name, the currency, and whether the amounts match the prices displayed in the UI.
3. Terms of service content: does it state the units sold (messages, tokens, generations, seats), the monthly limit, what happens at the limit, refund eligibility for a digital service, and how cancellation works and when it takes effect.
4. Terms acceptance: is there a checkbox at checkout and is the acceptance stored with a timestamp and user id.
5. Metered usage: is there a per-user hard cap, a way for the user to set it, and an alert at 80%.
6. Stripe receipts enabled and a support email configured.
7. Webhook handler verifies the Stripe signature before reading the payload, and no test-mode key can reach the production build.
8. A working refund path from the app or an admin route.

For each item output: PASS, FAIL, or NOT FOUND, the evidence, and the smallest change that fixes it.

Read the source