Developer pack
Claude Skill
Auth & Payments Setup
Wires sign-in and paid checkout into an existing app — without rolling your own auth or ever touching card data.
What it does
Integrates an auth provider (Supabase Auth, Clerk, or Auth.js) and payments (Stripe Checkout or Lemon Squeezy) into an app that already exists: the sign-in flow, the env-var and webhook surface, and the entitlement check that gates paid features. Built around one rule — don't build auth or store cards yourself — so you ship the wall solo builders hit right after their first deploy.
When to use
- ✓Your app works but anyone can use it — you need real sign-in
- ✓You want to charge for it and need checkout + "who paid" tracking
- ✓Adding a paid tier or gating a feature behind a subscription
When not to use
- ✗A purely internal tool with no external users or payments
- ✗You need a full billing system (metered usage, invoicing, tax) beyond simple checkout
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/auth-and-payments-setup.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: auth-and-payments-setup
description: Use when adding sign-in or paid checkout to an existing app. Triggers on "add authentication", "add login", "Supabase Auth", "Clerk", "Stripe checkout", "add payments", "gate this behind a subscription", "who paid".
---
# Auth & Payments Setup
Two rules carry this whole skill: **don't build your own auth**, and **never let card data touch your server**. Use a provider for each. The work is integration and the entitlement check — not invention.
## Auth
Pick a provider for how the app is built:
- **Supabase Auth** — if you're already on Supabase (Postgres + RLS); auth and data in one place.
- **Clerk** — fastest drop-in for React/Next with prebuilt UI; you trade some lock-in for speed.
- **Auth.js (NextAuth)** — most control, more wiring, no vendor.
Wire it in three parts: (1) the sign-in/sign-up flow, (2) a server-side session check on every protected route or action, (3) row-level protection so a logged-in user can only read their own data. Never trust the client to enforce access.
## Payments
- **Stripe Checkout** — the default. You redirect to Stripe's hosted page; cards never hit your server (this is what keeps you out of PCI scope). Lemon Squeezy / Paddle if you want a merchant-of-record handling sales tax/VAT for you.
- The flow: create a Checkout Session server-side → redirect → Stripe processes → a **webhook** tells your backend "this user paid."
- **The webhook is the source of truth, not the success redirect.** A user can close the tab before the redirect; the webhook still fires. Grant entitlements on the webhook, verify its signature, and make it idempotent (Stripe retries).
## The entitlement check
Store "this user/account owns X" in your database, set it from the webhook, and check it server-side wherever a paid feature is gated. One function: `hasAccess(user, feature)`. Gate on the server, not by hiding a button.
## The env + secret surface
API keys for auth + Stripe, the webhook signing secret, and the success/cancel URLs — all in environment variables, never in client code. Use Stripe **test mode** keys until the flow works end to end, then swap to live.
## Anti-patterns
- Rolling your own password storage or session crypto
- Granting access on the success redirect instead of the verified webhook
- An unverified or non-idempotent webhook (forged calls, or double-grants on retry)
- Checking entitlements only on the client
- Live Stripe keys before the flow is tested
Example prompts
Once installed, try these prompts in Claude:
- Add Supabase Auth (email + Google) to my Next.js app and gate the dashboard behind it.
- Wire Stripe Checkout so users can buy a one-time $19 plan, and unlock a feature once they've paid.