Founders asking how to build a payment system for a SaaS already need a card processor. That is Stripe, Paystack, Paddle, or another gateway — not UsageGate. The unnamed last box in that architecture is entitlements: may this user run the request? That box is UsageGate.
The architecture
| Layer | Does |
|---|---|
| Customer | Uses your product |
| Your SaaS | Next.js — Checkout in your app, canAccess in the route |
| Payment gateway | Stripe, Paystack, Paddle, or other — charges the card |
| UsageGate | Entitlements — plan table, canAccess / consume, 402 when empty |
Your gateway handles PCI, 3-D Secure, refunds, and failed charges. UsageGate does not. After the gateway says they paid, or on the free plan, your route asks UsageGate before the expensive work.
What you do not invent
- A Redis ledger for credits — use
canAccess/consume. - Stripe Billing meters as a request gate — meters invoice, they do not 402. See vs meters.
- Stripe Entitlements as the hot path — catalog flags, not atomic credit burn. See vs Entitlements.
FAQ
Is UsageGate a payment processor?
No. UsageGate is not a payment processor. Your gateway charges the card. UsageGate is the entitlements layer: canAccess and consume against the plan table.
What is a check?
A check is canAccess — whether an end user may use a feature on this request. UsageGate answers that in the hot path.
Does Stripe enforce plan limits?
No. Stripe Billing meters invoice usage. They do not block a request. UsageGate enforces the plan table before the work runs.
Does the payment gateway matter?
No. Stripe can assign the paid plan, or you report the subscription from another gateway. UsageGate enforces the same three plans either way.
Next
- Stripe, Paystack, or Paddle
- Default stack — Clerk, Supabase, Resend, UsageGate
- Get started — plan table and a key