You saw it on Hacker News yesterday. A merchant, apparently robbed blind by customers who bought stuff, got it, and then hit up their credit card company to say, ‘Nope, didn’t buy that!’ And Stripe? According to the guy who lost thousands, Stripe just shrugged.
This post, from the gingerlime folks, has blown up. 146 points and climbing. The comments section is a war zone of developers trading war stories about chargebacks. The general vibe? Stripe’s system is rigged against the little guy. Apparently, their support team even admitted they don’t share fraud signals between merchants. So, a scammer can fleece one Stripe user and then turn around and do the same to the next, completely clean.
This matters. Big time.
Progenix, my employer, runs its whole dang billing on Stripe. All our tiers – the free one, the $49/mo, $149, even the $499 – they all go through Stripe’s payment pipes. When the very community we serve, the developers, starts yelling about trust and billing, we owe them more than just PR spin.
Here’s the deal: friendly fraud. Why we still stick with Stripe. And what we’re actually doing to fight this mess.
The heart of the gingerlime argument is pretty simple: Stripe doesn’t seem to keep a shared fraud intel database across all its merchants. So, if some joker disputes charges with five different Stripe clients, to Stripe, it looks like five separate, unrelated incidents. No pattern. No red flag. Each merchant is left to fight their own battles. And guess what? The card networks – Visa, Mastercard – they usually side with the customer. You can have all the evidence in the world, but if the cardholder says ‘nah’, you’re toast.
This isn’t a glitch. It’s how the payment game is played, dictated by card network rules. Take Visa’s “reason code 83” – “fraudulent transaction — card absent environment.” The burden of proof lands squarely on you, the merchant, to prove the cardholder actually wanted and got the service. For digital goodies – SaaS, API credits, downloads – that’s a nightmare. No signature. No delivery confirmation photo. Zip.
Stripe’s dispute process is basically a text box and a file uploader. You type your story, attach some jpegs, and pray some algorithm upstairs reads it correctly. The gingerlime dude documented a case where Stripe punted his evidence before a human even glanced at it. The credit card company took the customer’s word. He lost.
That’s the problem. Here’s why we aren’t jumping ship.
Every payment processor has a chargeback headache. PayPal? Infamously opaque dispute resolution. Braintree? Better tools, but you’ll spend days integrating them. Adyen? They’re for the big leagues, the six-figure monthly spenders, and their sales process is a marathon. Paddle and Lemon Squeezy? They’ll eat the chargebacks, but their fees are a bloodbath – 5% + $0.50 per transaction. Brutal for a $49/mo SaaS.
Stripe, for an early-stage SaaS outfit, is still the least-worst option. Three reasons:
Developer Bliss. Stripe’s API, SDKs, webhooks – nobody touches ‘em. The checkout.session.completed
→ customer.subscription.updated
→ invoice.payment_failed
flow? Well-documented, battle-tested. Our billing setup took a couple of days, not weeks. The webhook handlers are so clear, one engineer can grasp the whole thing.
Tax Wizardry. Stripe Tax handles VAT, GST, US sales tax automatically. If you’re planning to sell worldwide from day one, this isn’t a luxury. Manual tax compliance is a full-time job for a whole department. Stripe’s auto-calculating tax saves us from regulatory headaches that would otherwise eat up engineering and legal hours.
The Customer Hub. Stripe’s customer portal lets users update cards, see invoices, manage subscriptions – no need for us to build any of that UI. For a small team hustling an MVP, that’s not a nice-to-have. That’s the difference between launching next month and launching three months from now.
But just because we use Stripe doesn’t mean we trust it blindly. It means knowing where their built-in protections stop and building our own defenses for the inevitable gaps.
We look at friendly fraud as an operational risk to be managed, not some fringe, theoretical problem. Here’s the stack we’ve built on top of Stripe’s foundation.
A rookie mistake – and the gingerlime article hammers this home – is letting customers into your product based on the Stripe Checkout success URL. That URL fires when the customer lands on it, not when Stripe actually captures the payment. So, they can get to your thank-you page, grab your product, and then dispute the charge.
At Progenix, access is provisioned only when the checkout.session.completed webhook fires. That’s after Stripe gives us the thumbs-up on the payment. If that webhook doesn’t hit? No subscription access. Period. This one design choice alone nips a whole category of ‘got the goods, paid nothing’ problems in the bud.
Every webhook handler we’ve got at Progenix is designed with the assumption that it might be a fraud attempt. We’re not just checking if a webhook arrived; we’re checking its origin, its timing, and cross-referencing with other events. It’s a tedious process, sure, but it’s way cheaper than losing thousands to chargebacks.
Think of it this way: Stripe gives you a solid lock on your front door. That’s great. But if you’re in a neighborhood with a lot of smash-and-grab artists, you might want to add a security system, deadbolts, and maybe a guard dog. We’re installing the security system.
Why We Stick With Stripe Despite the Flaws
The core of Progenix’s decision to continue using Stripe, even with its known chargeback vulnerabilities, boils down to pragmatism and a developer-first ethos. The gingerlime article highlighted a critical failing: Stripe’s lack of a cross-merchant fraud reputation system, which leaves individual merchants exposed to repeat offenders.
This is a significant problem. A customer who successfully defrauds one Stripe merchant is effectively a free agent, able to target others without consequence within Stripe’s ecosystem. The card networks, with their inherent bias towards the cardholder, often side with the consumer in disputes, making it an uphill battle for merchants, especially those selling digital goods where proof of delivery is inherently more complex. The evidence submission process, often reduced to a text box and file upload, feels like yelling into the void.
However, the alternatives are often worse for early-stage SaaS companies. PayPal’s dispute resolution is notoriously opaque. Braintree, while offering more strong tools, requires a significant investment in development resources. Enterprise-focused solutions like Adyen come with steep barriers to entry and higher costs. Services that take on merchant-of-record liability, like Paddle and Lemon Squeezy, impose fees that can cripple the margins of lower-priced subscription plans.
Stripe’s unparalleled developer experience, including its well-documented APIs, strong SDKs, and straightforward webhook system, significantly reduces the time-to-market for new products and features. Furthermore, Stripe Tax automates complex international tax compliance, a Herculean task for any small business operating globally. The included customer portal also offloads the burden of building and maintaining subscription management UI, freeing up valuable engineering cycles.
Building a Fraud Defense Layer Over Stripe
The critical insight here is that relying solely on Stripe’s default fraud protection is akin to leaving your front door unlocked in a high-crime area. Progenix’s strategy is to treat friendly fraud as an operational risk that requires active mitigation, rather than an abstract possibility.
The primary defense implemented is tying subscription activation to verified payment confirmation via webhooks. Specifically, access is granted only after the checkout.session.completed webhook is received and processed, ensuring that the payment has been successfully captured by Stripe. This is a crucial step that prevents users from gaining access to services and then initiating a chargeback.
Beyond this, Progenix is implementing a layered approach to webhook handling. Every webhook received is not just processed but also scrutinized. This includes verifying the source of the webhook, checking its timing against expected patterns, and cross-referencing event data with other transactional signals. This meticulous approach, while requiring additional engineering effort, builds a more resilient system against sophisticated fraud attempts. It’s about adding a strong security system on top of the basic lock Stripe provides.
Who is actually making money here?
Let’s cut through the noise. The card networks (Visa, Mastercard) win regardless. They take their cut on every transaction, and they benefit from the cardholder’s protection policies, which encourage more card usage. Stripe, as a payment processor, makes money on transaction fees. The more transactions they facilitate, the more they earn. Even with chargebacks, they likely have internal processes and fee structures that mitigate their direct losses, shifting much of the burden onto the merchant. The real losers in this scenario are the merchants, particularly smaller SaaS businesses, who are on the hook for the lost revenue, associated fees, and the administrative cost of disputes.
What does gingerlime’s post mean for other developers?
It’s a stark warning. It means you can’t just ‘set it and forget it’ with your payment processor. You need to understand the inherent risks, especially with digital goods and subscriptions where proof of delivery is hard. It’s a call to action to build your own fraud detection and mitigation strategies on top of whatever platform you use. Don’t assume your processor has your back against sophisticated fraudsters.
Will Stripe fix their fraud problem?
That’s the million-dollar question. They could implement better cross-merchant fraud signal sharing, but that likely involves significant technical investment and a potential shift in their relationship with the card networks. Given their current business model, where they profit from volume, and the industry-wide nature of chargeback issues, a complete overhaul isn’t guaranteed. Expect incremental improvements rather than a fundamental change anytime soon. For now, merchants are largely on their own.
