I built a payments app solo. Stripe killed it. Here’s the post-mortem.

PoolJar was supposed to solve a small, universal annoyance: collecting money from a group. Team fees, group trips, office gifts — someone always fronts the cash and then spends three weeks chasing Venmo requests. I built the fix: create a pool in under two minutes, share a living link, and everyone pays with Apple Pay or Google Pay in seconds. No app, no accounts, no chasing.

I designed it, built it, and shipped it alone under my studio, G6 Studio. Frontend, backend, payments integration, the AI features that wrote your nudge messages and thank-you notes — all of it. I’d been laid off from my job on January 20th; the idea came about a week later, and full focus started in early February. The first few weeks went to incorporating G6 Studio, picking a name — it was originally “Pooly,” until domain conflicts killed that — plus design and infrastructure, alongside some early consulting work under the same studio. PoolJar went live March 5th, about five weeks after I started building in earnest.

Real people used it for real things immediately, before I’d done any marketing. My wife created the first pool, a birthday gift collection for a friend, as a live test — it raised $206.18 from 10 contributors, with zero bugs reported and unprompted feedback that it was easy to use. My sister-in-law split a $61.05 restaurant bill three ways; one contributor suggested a QR code so people could join without a link, and I shipped that the next day. The largest pool, an end-of-season appreciation gift from a youth soccer team to its coach, raised $286.22 from 14 contributors — the most anyone put into a single pool. In total, organically, PoolJar processed 11 pools and roughly $1,550 in contributions.

And then Stripe shut it down.

What actually happened

PoolJar moved money through Stripe: contributors paid in, organizers got paid out to their bank accounts. Which meant that from Stripe’s point of view, I wasn’t a software company — I was a payments company, with everything that implies.

On March 20th, my father passed away, and I flew to the Philippines. I wasn’t at the dashboard. That’s around when someone found PoolJar’s gap: card testing first — small authorization attempts to find live cards — then a bot script contributing to its own pools, $10 to $15 at a time, in rapid bursts, on international credit cards. Stripe caught some of it automatically and emailed me the blocks; I read those as the system working and didn’t dig further, since I had other things on my mind. On the flight home, the same pattern showed up again on a new pool — the tell was speed and volume, more contributions in a few minutes than a real pool sees in a week — and that’s when I understood what I was looking at.

I built countermeasures over the following week: restricted card acceptance to US and Canadian cards only, added Cloudflare Turnstile to stop the scripted contributions, and added heuristics on the two markers the fraudster kept reusing — all-caps display names, gibberish email addresses. It worked. The next two pools he tried hit the filters immediately, contributions blocked, pools auto-held. But the fix only stopped fraud that hadn’t happened yet. The transactions that had already gone through were Stripe’s problem now, and Stripe’s risk team responded the way risk teams do.

The sequence: a first notice on March 25th that a likely-fraudulent payment had been blocked. A second notice on April 6th, tied to the same earlier fraud, while my countermeasures were already live and working. On April 8th, Stripe closed the account and asked for documentation to support reinstatement; I sent everything the same day. Later that same day, a final email: the account would stay closed, permanently. There was no appeal that mattered — I asked more than once and got the same answer back.

Then the disputes started arriving — cardholders’ banks filing chargebacks on the fraudulent transactions weeks after the fact, plus Stripe’s $15 fee on each one, on an account that had already been closed. I emailed Stripe every time with the list of transactions I’d already flagged as fraud, asking them to reverse those specific charges before a bank could dispute them. I learned the hard way that’s not really a lever you get to pull — once a cardholder’s bank files a chargeback, it runs on card-network rules, and neither Stripe nor I could stop it, whatever I’d already flagged on my end. Twenty disputes went through between April and June: $261 in transaction amounts plus $300 in fees, charged directly to my bank account. On May 2nd, my last support ticket closed without action, and I stopped fighting it.

PoolJar didn’t fail slowly with a churn problem I could have fixed. It failed inside about two weeks in late March and early April — and the fact that I’d already found the fix and shipped it didn’t change the outcome, because the fix only protected the future. The account, and the business under it, was judged on what had already happened.

None of that fraud was mine, and I never saw a dollar of it. But it ran through my platform because I hadn’t built enough friction to stop it, and that part is on me.

Worth saying plainly: this wasn’t a large business. Eleven pools, roughly $1,550 in total volume, $561 eaten in fees and disputes. I’m not telling this story because the number was big — I’m telling it because the number didn’t need to be. A payment processor’s risk decision doesn’t wait for you to hit some threshold of scale before it becomes existential to your business. At $1,550 in lifetime volume, one email ends the company exactly as completely as it would at $1.5 million. Size doesn’t change the mechanism. It only changes how much runway you have to notice the risk before it finds you.

What I got wrong

Not the code. The code worked — biometric checkout converted well, the living links did their job, people who used it liked it. What I got wrong was the shape of the business.

I thought I was building an app with payments in it. I was building a fintech with an app around it. The moment money moves through your platform, fraud prevention isn’t a feature on the roadmap — it’s the product’s foundation. I built the delightful parts first and treated risk as a later problem. Case in point: I assumed Stripe’s identity verification blocked someone from creating a pool until they’d been approved. It doesn’t, not by default — a Connect account can start transacting before verification finishes unless you explicitly configure it to require that first. I hadn’t. Fraudsters are extremely good at finding platforms where risk is a later problem.

I built on a single point of failure and called it infrastructure. Stripe is excellent software. It is also a counterparty with unilateral power over my revenue, my users’ money, and my company’s existence. I had no second processor, no fallback, no leverage. “Powered by Stripe” was on my landing page as a trust signal; it should have been in my risk register as a dependency.

I picked a structurally hard business and made it harder. Consumer users, episodic usage (how often do you organize a group pool — three times a year?), free-to-create pricing, and thin payments margins that fraud losses obliterate instantly. Every one of those is survivable; all four together, solo and bootstrapped, is walking uphill in ice skates.

What I’d tell you if you’re building on a payment processor

Treat any platform that can end you as a risk to engineer around, not a vendor to integrate. Concretely: know your processor’s prohibited-and-restricted categories cold, because “collecting money on behalf of others” often lives near the edge of them. Build fraud controls before you build growth features — velocity limits, verification on whoever receives payouts, holds on fast-moving money. Keep enough separation in your architecture that a second processor is a sprint away, not a rewrite away.

I say that knowing how hard it is to actually execute. When I went looking for a second option after the fact, PayPal’s enterprise team never called me back, and most others didn’t reply to my emails at all. The one company that did respond, Finix, was still only onboarding established organizations — soccer clubs, restaurants, businesses with a legal entity behind every account — not individuals, which was most of PoolJar’s actual user base. There may not have been a real second option for a business shaped like mine. That’s its own lesson: find out before you build, not after.

And if you can get someone else to be the merchant of record — so the fraud and chargeback liability lands on their balance sheet instead of yours — seriously consider paying that tax. I’ll be doing that for everything G6 Studio sells from now on.

What survived

The uncomfortable truth about PoolJar is that it was simultaneously a failed business and the best proof of capability I’ve ever produced. One person shipped a full-stack payments product with biometric checkout, AI-generated messaging, and a real user base — design, architecture, implementation, operations. That capability didn’t get shut down. It’s what G6 Studio sells now: I build products for clients — AI features shipped into existing apps, marketing sites, frontend architecture — with all of the shipping ability and, now, a hard-earned respect for the failure modes.

PoolJar the product is gone. PoolJar the education is the most expensive and most valuable thing I own.