Designing a SaaS API Gateway with Tiered Access and Stripe Credit Billing
How I architected Inflectiv — a scalable API gateway with custom rate limiting, auto-generated OpenAPI docs, multi-tier access control, and end-to-end Stripe credit billing. The monetization engineering behind a real SaaS product.
Selling an API is easy to say and hard to ship. The moment money is attached to requests, three boring-but-unforgiving problems appear at once: you have to count usage accurately, enforce limits per tier, and charge for it without double-billing or letting a customer overrun their plan. Inflectiv is the external API gateway and monetization engine I built to do all three — custom rate limiting, automated OpenAPI documentation, multi-tier access control (Free, Basic, Pro), and an end-to-end Stripe-powered credit billing system.
This is the unglamorous backend engineering that turns a product into a business.
The three problems money creates
Built on Python, FastAPI, Redis, PostgreSQL, Stripe, and OpenAPI, the gateway sits in front of the product API and has one job: let the right requests through, count them honestly, and bill for them correctly.
1. Rate limiting that respects tiers
A Free user and a Pro user can't share a limit. Rate limiting had to be per-key and per-tier, with the tier resolved on every request. I used Redis as the counter store — it's the right tool because rate-limit counters are high-write, short-TTL, and need to be atomic. A sliding-window/token-bucket counter in Redis gives you accurate enforcement without hammering the primary database on every call.
The trap here is doing the counter increment and the limit check non-atomically — under concurrency that leaks free requests. The increment-and-check has to be a single atomic operation.
2. Multi-tier access control
Free, Basic, and Pro aren't just different numbers — they can gate different endpoints and features. The access layer resolves an API key to its tier and its entitlements before the request reaches business logic. Thin gateway, clear boundary: authentication and authorization happen at the edge, and the product code behind it never has to know about billing tiers.
3. Credit billing with Stripe
This is where correctness matters most, because mistakes cost real money in both directions. The billing system tracks credits, decrements them against usage, and reconciles with Stripe for payment. The non-negotiables:
- Idempotency. Stripe webhooks can fire more than once. Every billing operation has to be idempotent or you double-charge — the fastest way to lose a customer.
- Webhooks as the source of truth. Payment state comes from Stripe's webhook events, not from the client telling you "I paid." Trusting the client is how you get fraud.
- Decrement before serve, reconcile after. Credits are checked and held before an expensive operation runs, not after, so a customer can't overrun a depleted balance under concurrent requests.
Automated OpenAPI documentation
An API nobody can read doesn't sell. FastAPI's OpenAPI generation meant the docs stayed in lockstep with the actual endpoints automatically — no drift between what the docs claim and what the gateway does. For a product where customers integrate against your contract, that accuracy is the product.
What this demonstrates
Monetization is a systems-correctness problem. Rate limiting needs atomic counters, access control needs a clean edge boundary, and billing needs idempotency and a single source of truth. Get any one wrong and you either leak revenue or charge people twice — both fatal for a young SaaS.
I'm Haris Ahmed, a full-stack software engineer and AI engineer who builds production SaaS backends — API gateways, billing systems, and the unglamorous infrastructure that makes software a business. See more at harisahmed.dev.