Rate limiting (Upstash)

Server Actions that create Stripe sessions are abusable: a bot can call them in a loop and create thousands of Checkout sessions per minute. Stripe will accept them all (they're free until paid). Rate limiting puts a brake on it — and it's per-IP, so one bad actor doesn't lock out everyone.

The two limits

• Checkout: 10 requests / 60 seconds per IP (sliding window).
• Portal: 20 requests / 60 seconds per IP (sliding window) — more lenient since reaching the portal already means the user is authenticated.

Turn it on

# Upstash console → Create database → "REST API"
UPSTASH_REDIS_REST_URL="https://xxx.upstash.io"
UPSTASH_REDIS_REST_TOKEN="AXxx..."

Graceful degradation when not configured

When the Upstash env vars are absent, the limiter constructors return null. checkRateLimit(null, id) returns { allowed: true } — every request passes. This means dev works without Upstash and ALL callers don't need to check "is Upstash configured?" themselves.

// src/lib/rate-limit.ts
export const checkoutRateLimiter = redis
  ? new Ratelimit({
      redis,
      limiter: Ratelimit.slidingWindow(10, "60 s"),
      prefix: "ratelimit:checkout",
    })
  : null;

// In the Server Action:
const result = await checkRateLimit(checkoutRateLimiter, ip);
if (!result.allowed) {
  return { success: false, error: `Try again in ${result.retryAfter}s.` };
}

IP extraction — proxy headers, in order

// src/actions/checkout.ts → getClientIp()
x-forwarded-for  → first IP in the comma-separated list (the client)
x-real-ip        → fallback for some Nginx setups
"unknown"        → final fallback (all unknown IPs share one bucket — fine for dev)