01

Two months. I built a complete payment and consumption system. Totally unexpected, honestly.

End of January, as I was wrapping up my first project, I asked myself a question: "Besides credit-based pricing, what other pricing models exist for SaaS?"

Just that one question opened a door I never saw coming.

02

I studied successful cases, broke them down one by one, and identified 4 revenue models — lifetime purchase, unlimited subscription, pure credits, and quota-based subscription (subscription + credits). These cover about 95% of the lean and profitable SaaS models out there.

Then I thought, "What if I could build all 4? For future projects, just toggle a config, tweak some copy and prices, and go live?"

Just thinking about it got me excited.

With my years of development experience, I was 80-90% confident it could be done. So I went for it.

03

But as I built, I realized the water was deeper than I thought.

Creem and PayPal let you create trial products, but there's no parameter to make them non-trial. This means users could trial indefinitely, even cancel before trial ends. That directly impacts revenue, right?

Subscription upgrades/downgrades — PayPal's official upgrade logic has a loophole: upgraded plans only charge in the next billing cycle.

Meaning, a user upgrades to Pro today, gets Pro features tomorrow, but payment doesn't happen until next month. Even worse, they can cancel the day before billing and get 10+ days of Pro for free. You get zero dollars.

If you don't know this rule, you're delivering service without getting paid, and you won't even know what went wrong. You have to use a workaround though, because you can't just block users from upgrading, right? Solutions need to be defined.

Credit consumption order — do you consume subscription credits first, or purchased credits? Different orders = completely different user experiences.

Every decision required tons of thinking and testing.

Sure, AI wrote tons of code for me, but for trickier logic, it couldn't give optimal answers. I had to think it through myself, reason it out, verify it. But ultimately, I got it done, and the user experience is pretty good.

And this is where the real time went. Integrating payments isn't hard — what's hard is handling every "What if the user does this? Did I handle it properly?"

I handled all these edge cases one by one —

Upgrades take effect immediately, downgrades wait for current period to end; cancellations retain access until expiry; duplicate subscriptions don't double-charge; gifted credits expire via auto-scan; concurrent consumption uses database atomic operations to prevent over-deduction, etc...

16+ scenarios, all covered.

Truly zero code — just edit config files to change pricing models and modify plans.

# Pricing Models
## credits     - Pay-as-you-go (could be credits, bandwidth, API calls, tokens, requests, etc.)
## subscription_unlimited - Subscription with unlimited usage during period (may include trial)
## subscription_quota    - Subscription with fixed quota per period, extra purchases allowed
## lifetime              - One-time payment for permanent access
NEXT_PUBLIC_PRICING_MODEL=subscription_quota
# Modify plans
const SUBSCRIPTION_PLANS = {
  basic: {
    priceMonthly: 9.99,
    priceYearly: 99.99,
    priceMonthlyCNY: 29,
    priceYearlyCNY: 299,
    name: 'Basic',
    features: ['xx'],
    quota: 100    ...  },
  pro: {
    priceMonthly: 29.99,
    priceYearly: 299.99,
    priceMonthlyCNY: 99,
    priceYearlyCNY: 999,
    name: 'Pro'    ...
}

But finishing payments isn't enough. There's consumption too.

Once a user subscribes, how do you check permissions? Different pricing models have different permission logic.

What about fulfillment? Also different. For code-based products with lifetime pricing, fulfillment doesn't even happen on the website.

And quota subscriptions — not just subscription credits, but also gifted credits and purchased credits. All need proper handling.

If every project requires rewriting consumption logic, this whole thing doesn't truly close the loop.

So naturally, I had to abstract it out, no hard-coding. I redesigned everything, encapsulating credit consumption, permission control, and state management, exposing just one method. Call it and done.

In the end, one method for permission checking, one for consumption. Clean enough, and sufficient, isn't it? 95% of SaaS products, regardless of their form — writing/images/videos/etc — essentially boil down to permission checking and credit consumption. Nothing else. Everything is consumption — count, times, whatever you call it, it's all credit consumption.

// Check user permissions
useService('use')
// Check permissions + consume credits
useService('consume', 9)

04

What about payment methods?

Considering domestic vs international transaction fees, I did the math — the cost of a Chinese domain, server, and ICP filing is far less than the fee loss from international channels. So domestically I use Alipay alone, internationally I use Creem and PayPal.

I also integrated Stripe, though I don't have a production account yet. But getting it ready early means I won't have to worry about payments later, right? Ultimately, just one config.

# Payment Providers
## Options: alipay, creem, stripe, paypal — comma-separated, controls which buttons show on pricing page
## If not configured, .cn defaults to alipay, international defaults to creem,paypal
NEXT_PUBLIC_PAYMENT_PROVIDERS=creem,paypal
# creem config...
# paypal config...

So how simple is it to use this system?

Overall, for payments: zero code, just change config. For user permission control and consumption: 2 lines of code, done.

In the end, 4 pricing models x 4 payment methods, all working. This definitely wasn't what I expected when I started. This is Pay4SaaS. With it, whether it's AI writing, image generation, video creation, or any other SaaS, you can easily monetize with a complete loop.

How long did it take to build this entire system? 300+ hours. And that's with extreme focus, countless pitfalls, and repeated overhauls. If you built from scratch yourself, it'd likely take even longer.

05

But that's what makes it truly complete monetization infrastructure.

Why did I insist on getting payments and consumption right?

Because from the start, I was clear-headed — if I half-assed it now, every new project would require patching holes. After patching, I'd still have to maintain previous projects, endless trivial tasks. Anyone who's maintained multiple projects knows this nightmare.

I got into indie hacking for time freedom, to escape these trivialities and do more valuable things. A profitable SaaS = core features + monetization loop (payment + permission control + consumption). If this isn't done right, freedom is just empty talk. It might even become an occasional nagging worry in life. That's not what I want.

So, getting paid right + letting authorized users consume properly is the prerequisite for any SaaS. The 300+ hours of pitfalls I navigated, you don't have to anymore.

Check out pay4saas.com if you need it. After purchase, feel free to reach out if you have questions.