How It Works
A Firebase-native Next.js stack with auth, Stripe billing, and usage quotas wired end-to-end. Here is exactly how a request flows through it — and why each step still does the right thing when something fails.
The Flow
User signs up
Firebase Auth verifies identity by email OTP or Google. On success a signed, httpOnly session cookie is issued server-side. One email always maps to one account — whether they used a code today and Google tomorrow.
Every request is guarded
Edge middleware checks the session cookie before a protected page renders. API routes then re-verify it against Firebase with revocation checking — so a deactivated or signed-out account loses access on the very next request.
Your feature runs within budget
Before any billable work, your route reserves a quota slot in one atomic Firestore transaction. If the work later fails, the slot is refunded automatically — no race conditions, no leaked usage.
Stripe is the source of truth
Checkout creates the subscription, but the Stripe webhook — not the browser redirect — writes the entitlement. It's idempotent and out-of-order safe, and a reconciliation cron repairs any drift if a webhook is ever missed.
Auth
Firebase Auth with server-side session cookies. 14-day httpOnly sessions, revocation-checked on every request, CSRF-protected.
Read the auth docsPayments
Stripe Checkout + billing portal, with the webhook as the single source of truth. Configure tiers in config/pricing.config.ts.
Read the payments docsQuotas
Atomic check-and-reserve in a single Firestore transaction, with auto-refund on failure. Race-condition-proof metering.
Read the quotas docsSecurity by Default
A tuned Content-Security-Policy and full security-header set, Firestore-backed rate limiting, tested Firestore rules that keep entitlements server-only, CSRF protection on every mutation, Zod validation on every input, timing-safe secret checks, and PII-redacting logs — all preconfigured. Read the full rundown in the security docs.