Why is setting up payments for side-projects still so heavy, and would you use a self-hosted app to avoid the Stripe setup?
Every time I start building a new SaaS, the checkout phase feels like hitting a wall. You have to write custom logic for customer database states, set up secure webhook listeners to track renewals, and completely lock your architecture into Stripe's ecosystem from day one.
I got tired of writing the same payment boilerplate, so I started building an open-source alternative to Stripe Checkout called Paycan.
The goal is to treat payment integrations like a simple plug-in middleware layer.
No Provider Lock-In: It acts as a unified API. You can switch between Stripe and PayPal by changing a config file, without modifying your core database or app code.
Minimal Boilerplate: It drops into a project in around 10 lines of code. It handles the subscription tracking and transaction events so your main app doesn't have to.
Self-Hosted: It runs on your own server (built with Laravel & Vue, licensed under AGPLv3) so you maintain full control over the data layer.
It’s currently in an active pre-production phase—fully functional for testing and validation, but we are actively hardening it before calling it production-ready.
I’m trying to figure out if fellow indie hackers actually care about avoiding provider lock-in early on, or if the initial convenience of native SDKs outweighs the long-term technical debt.
How do you usually handle payments on your new projects? Do you just copy-paste your old Stripe webhook code, or would a decoupled, self-hosted layer like this save you time?
The repository is open-source if you want to look at the architecture:
https://github.com/paycan-app/paycan
Provider lock-in is a real fear but I'd guess most indie hackers care about it in theory more than in practice, until the day they actually need to switch, at which point it becomes urgent fast. The harder sell might be trust, are people comfortable self-hosting something that touches payments, or does that feel riskier than just accepting Stripe's lock-in. Have you gotten a read yet on which side people fall on, convenience or control?
One thing nobody's mentioned yet: self-hosting a payments middleware shifts the operational burden onto you in a way that's easy to underweight early on. Stripe's SDK is a dependency; a self-hosted payment layer is infrastructure you now have to patch, monitor, and keep available 24/7, because if it goes down, checkout goes down with it - that's a different risk profile than "provider lock-in," and for a solo builder it might be the bigger cost.
Also worth flagging for anyone considering it commercially: AGPLv3 has network-use copyleft (the loophole regular GPL leaves open that AGPL closes) - if you're running a modified version of Paycan as part of a hosted product you offer to others, that can trigger source-disclosure obligations depending on how it's deployed. Worth reading closely before building on it, not after.
The interesting competition isn't Stripe—it's the decision to tightly couple billing with your application architecture. I'd keep validating whether developers are buying payment abstraction or confidence they can change providers without rewriting core business logic later.
The 10-line install is not the hard portability test; moving a live subscription is. I'd validate one ugly migration: active Stripe plan with a trial, coupon, failed renewal, and refund -> PayPal, with an auditable state diff and no double charge. If that round-trip works, "switch by config" becomes more than a checkout abstraction.
The lock-in question splits cleanly: creating a charge unifies fine across Stripe and PayPal, but webhook verification is where they don't — the two sign differently and expect different replay handling. So the test that matters for Paycan is whether switching providers by config keeps verification equally strict on both sides, or whether the abstraction thins out at the one layer you can't loosen. That's what I'd harden first, ahead of the boilerplate win.