Stripe closed our account over upsell transaction architecture, not fraud
1 comments
Really sorry you’re dealing with this — what Stripe is doing here isn’t unusual, and unfortunately it’s a pattern that affects a lot of legitimate businesses.
Stripe’s risk engines (Radar + rules around “unauthorized payments”) will often treat multi-charge post-purchase upsells as suspicious when they show up as separate transactions on cardholder statements — especially if 3D Secure isn’t triggered. That looks exactly like a stolen card or automated abuse to their systems, even if technically every charge was authorized by the customer.
The really frustrating part — and the part most founders don’t understand — is that these holds/shutdowns aren’t just “policy decisions”, they’re risk capital decisions: processors are underwriting your future liabilities, not just moving money. When their automated systems trigger, human escalation rarely happens unless you can quantify and mitigate their perceived risk in a way that their compliance team understands. That’s why all the documents you submitted often still get you canned template responses.
A few points that might help others in this thread:
Transaction architecture matters as much as chargebacks: How upsell or one-click flows are implemented (multiple charges, stored tokens, missing authentication) is frequently why automated risk engines flag accounts — and you can fix the flows but still be left holding the bag afterward.
Merchants often don’t realize they’re carrying risk exposure until funds are frozen: You can have a low chargeback percentage but still trip rules if authorization patterns look abnormal to the processor. That’s why so many Shopify merchants never see this — Shopify’s implementation merges charges and preserves authentication.
There are ways to prevent this early if you plan ahead: Understanding how processors view risk, reserves, effective processing rate, and authorization architecture before you scale can literally save you tens of thousands and preserve your cash flow.
If you want to see a *clear, unbiased way to compare what you actually pay — including effective blended rate, reserves, and risk mitigation impact across processors — we built a free Effective Rate Calculator folks use to better plan and negotiate payment terms: https://effectiveratecalculator.com/
And if anyone in this thread wants to dig into how different processors (Stripe, PayPal, etc.) treat risk, reserves, rolling reserves, and accounts receiving holds, I’m happy to discuss patterns we see day-to-day from real merchant experiences.
Stripe’s risk engines (Radar + rules around “unauthorized payments”) will often treat multi-charge post-purchase upsells as suspicious when they show up as separate transactions on cardholder statements — especially if 3D Secure isn’t triggered. That looks exactly like a stolen card or automated abuse to their systems, even if technically every charge was authorized by the customer.
The really frustrating part — and the part most founders don’t understand — is that these holds/shutdowns aren’t just “policy decisions”, they’re risk capital decisions: processors are underwriting your future liabilities, not just moving money. When their automated systems trigger, human escalation rarely happens unless you can quantify and mitigate their perceived risk in a way that their compliance team understands. That’s why all the documents you submitted often still get you canned template responses.
A few points that might help others in this thread:
Transaction architecture matters as much as chargebacks: How upsell or one-click flows are implemented (multiple charges, stored tokens, missing authentication) is frequently why automated risk engines flag accounts — and you can fix the flows but still be left holding the bag afterward.
Merchants often don’t realize they’re carrying risk exposure until funds are frozen: You can have a low chargeback percentage but still trip rules if authorization patterns look abnormal to the processor. That’s why so many Shopify merchants never see this — Shopify’s implementation merges charges and preserves authentication.
There are ways to prevent this early if you plan ahead: Understanding how processors view risk, reserves, effective processing rate, and authorization architecture before you scale can literally save you tens of thousands and preserve your cash flow.
If you want to see a *clear, unbiased way to compare what you actually pay — including effective blended rate, reserves, and risk mitigation impact across processors — we built a free Effective Rate Calculator folks use to better plan and negotiate payment terms: https://effectiveratecalculator.com/
And if anyone in this thread wants to dig into how different processors (Stripe, PayPal, etc.) treat risk, reserves, rolling reserves, and accounts receiving holds, I’m happy to discuss patterns we see day-to-day from real merchant experiences.
Stripe shut down our account citing "unauthorized payments" and is holding ~$50K with plans to auto-refund customers who already received their products.
After investigating, we identified the root cause. Our checkout platform (CheckoutChamp) was processing post-purchase one-click upsells as separate Stripe charges, using the stored payment token without 3D Secure. About 64% of our customers accepted upsells, meaning the majority of orders generated multiple charges on customer bank statements. Customers who didn't recognize these separate charges likely triggered Early Fraud Warnings (Visa TC40/Mastercard SAFE) — which Stripe's Radar system picked up as "unauthorized" activity.
This is a transaction architecture issue, not fraud. The same upsell flow works fine on Shopify because Shopify's post-purchase API adds the upsell to the existing order rather than creating a new charge. CheckoutChamp creates separate charges.
We've already fixed this: disabled all post-purchase upsells, canceled all recurring subscriptions, and restructured the flow so future add-ons consolidate into one transaction.
We submitted 33+ documents through the dashboard (EIN, Articles of Organization, 6 months bank statements, supplier contracts, 3PL invoices, inventory photos, customer order confirmations). We offered a 15% rolling reserve. We showed them the customer emails proving full transparency.
Every support case gets auto-closed with a template response. No one has told us which specific transactions are "unauthorized." One response even referenced a completely different company name ("Greg Misc LLC" — we are JS Commerce Group LLC).
Today we received what appears to be a final rejection — again a template, with no acknowledgment of the root cause analysis we submitted two days ago. Stripe is now starting automatic refunds within 5 days to customers who have their products in hand.
We emailed Patrick Collison directly. We're running out of options.
Has anyone dealt with a similar situation where Stripe flagged legitimate post-purchase upsell charges as unauthorized? Interested in hearing what actually worked to get a human review.