aabddb592f
* feat(billing): multi-user seat gate: multi_user capability, 20-day grace, owner-only dormancy Multiple people in one company becomes a paid capability (multi_user, the eighth PAID key). Derived at access time from capability_grants, no status column, no enforcement cron: - entitled: active grant (trial/stripe/team/manual/comp), everyone works - grace: newest grant expired < 20 days ago; countdown banner for everyone in companies with > 1 user; invites still allowed - frozen: only role=owner resolves; other memberships go dormant (rows untouched, paying reactivates instantly); invites 403 with paid-plan upsell Enforcement: new resolve_active_company_gated RPC (zero-arg RPC and RLS twin untouched: they also run on self-hosts, where the gate never bites), gated query fallback for service-role/API-key paths, setActiveCompany guard, MCP company-access check, invite route. Middleware routes all-frozen users to a new /paused page; the switcher greys locked companies. Migration 20260901081417 (applied to staging): trial trigger seeds multi_user, backfills for mid-trial companies, active Stripe subs, team agreements, and a grandfather grant (expires now, i.e. grace = deploy + 20 days) for existing unpaid multi-member companies. Daily cron mails owners at grace start and last day. Strings in sv+en; pg-real + unit tests included. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L4tNt8wRG3a5iuU1JE2pnP * fix(billing): multi-user seat gate hardening from skeptic review - Stripe cancel now EXPIRES the multi_user stripe grant instead of deleting it: the 20-day grace window hangs on an expired row, so a deleted one froze churned payers' staff instantly with no banner and no mail. Other stripe grants keep the freeze-and-retain delete. - New SECURITY DEFINER company_multi_user_state() RPC (migration 20260901083726, applied to staging) and RPC-first getMultiUserState: capability_grants RLS hides team-scoped rows from non-team users, so user-client reads misread byra-covered companies as frozen (switch refusal, wrong switcher locks). - Byra-kind teams get a standing team-scoped multi_user grant (backfill + teams trigger): byra client companies have no company-scoped trial by design, so a grantless byra team would freeze every consultant and client user. - Comped/manual companies with active PAID-key grants extend to multi_user (a comped company must not read as paying while locking out user two). - /api/v1 gets the same dormancy gate as MCP (frozen non-owner -> 403). - PGRST202 on resolution fails OPEN (pre-migration DB has zero multi_user rows; the gated fallback would have frozen every non-owner mid-deploy). - Grace cron: covers team-scoped lapses (byra agreement ending) and skips the start mail for the hand-mailed grandfather cohort. - Tests updated/added across all touched surfaces; pg tests for the new RPC and byra trigger; trial-suppression pg test extended to 8 keys. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L4tNt8wRG3a5iuU1JE2pnP * fix(billing): decouple seat-gate env check and fail open on gate read throws CI round 1 on #2099: - isMultiUserEnforced no longer imports has-capability: several route test suites partially mock that module and the vitest mock guard threw from inside the v1 seat gate, turning expected 4xx responses into 500s. multi_user is never a connector capability, so the bypass reduces to the same env reads, now inlined. - getMultiUserState wraps its resolution in a fail-open try/catch: a client without .rpc or a thrown network error must never lock users out. - no-phantom-columns ceiling 391 -> 393 with reasons: the seat gate's .or() scope filter (server-resolved UUIDs) and the Stripe cancel expiry update's timestamp .or(); all columns in both strings are literals. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L4tNt8wRG3a5iuU1JE2pnP * fix(billing): membership-guard the multi-user entitlement RPCs (Superagent P3) company_multi_user_ok and company_multi_user_state are SECURITY DEFINER and were granted to authenticated with a caller-supplied company UUID: any logged-in user could probe an arbitrary company's billing state and grace deadline across tenants. Migration 20260901091752 (applied to staging) requires an auth.uid() membership in the target company when a JWT is present, keeps service-role/definer contexts unrestricted, and clamps the grace window to [0, 20] days. pg tests: stranger gets false/NULL, member reads normally, oversized p_grace_days cannot widen the probe. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L4tNt8wRG3a5iuU1JE2pnP --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
182 lines
6.9 KiB
TypeScript
182 lines
6.9 KiB
TypeScript
import type { SupabaseClient } from '@supabase/supabase-js'
|
|
import type Stripe from 'stripe'
|
|
import { CAPABILITY, PAID_CAPABILITIES } from '@/lib/entitlements/keys'
|
|
import type { BillingPlan } from './client'
|
|
|
|
/**
|
|
* Stripe → DB reconciliation for subscriptions. The single source of truth for
|
|
* paid access is capability_grants(source='stripe'); this module writes those
|
|
* grants from subscription state and removes them on cancellation
|
|
* (freeze-and-retain: only the stripe grants are touched, never bank tokens or
|
|
* AI data).
|
|
*/
|
|
|
|
// Statuses that should keep paid access on. past_due stays on as a grace window
|
|
// (Stripe's dunning retries the charge); access is revoked only once the
|
|
// subscription is genuinely canceled/unpaid.
|
|
const ACCESS_STATUSES = new Set(['active', 'trialing', 'past_due'])
|
|
|
|
export function statusGrantsAccess(status: string | null | undefined): boolean {
|
|
return !!status && ACCESS_STATUSES.has(status)
|
|
}
|
|
|
|
export interface SubscriptionState {
|
|
companyId: string
|
|
stripeCustomerId: string | null
|
|
stripeSubscriptionId: string | null
|
|
status: string | null
|
|
plan: BillingPlan | null
|
|
currentPeriodEnd: string | null // ISO
|
|
}
|
|
|
|
function planFromSubscription(sub: Stripe.Subscription): BillingPlan | null {
|
|
const price = sub.items.data[0]?.price
|
|
const priceId = price?.id
|
|
if (priceId && priceId === process.env.STRIPE_PRICE_YEARLY) return 'yearly'
|
|
if (priceId && priceId === process.env.STRIPE_PRICE_MONTHLY) return 'monthly'
|
|
// Fallback by recurring interval if env price ids aren't wired up.
|
|
const interval = price?.recurring?.interval
|
|
if (interval === 'year') return 'yearly'
|
|
if (interval === 'month') return 'monthly'
|
|
return null
|
|
}
|
|
|
|
// current_period_end lives on the Subscription in older API versions and on the
|
|
// subscription item in newer ones: read defensively so SDK/API drift can't
|
|
// break the build or the expiry calc.
|
|
function periodEndIso(sub: Stripe.Subscription): string | null {
|
|
const s = sub as unknown as {
|
|
current_period_end?: number
|
|
items?: { data?: Array<{ current_period_end?: number }> }
|
|
}
|
|
const unix = s.current_period_end ?? s.items?.data?.[0]?.current_period_end ?? null
|
|
return unix ? new Date(unix * 1000).toISOString() : null
|
|
}
|
|
|
|
export function subscriptionToState(sub: Stripe.Subscription, companyId: string): SubscriptionState {
|
|
return {
|
|
companyId,
|
|
stripeCustomerId: typeof sub.customer === 'string' ? sub.customer : (sub.customer?.id ?? null),
|
|
stripeSubscriptionId: sub.id,
|
|
status: sub.status,
|
|
plan: planFromSubscription(sub),
|
|
currentPeriodEnd: periodEndIso(sub),
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Reconcile a company's subscription state into the DB: upsert
|
|
* company_subscriptions, then either grant or remove the stripe capability
|
|
* grants. Idempotent: safe to run on duplicate/retried events.
|
|
*/
|
|
export async function applySubscriptionState(
|
|
supabase: SupabaseClient,
|
|
state: SubscriptionState,
|
|
): Promise<void> {
|
|
await supabase.from('company_subscriptions').upsert(
|
|
{
|
|
company_id: state.companyId,
|
|
stripe_customer_id: state.stripeCustomerId,
|
|
stripe_subscription_id: state.stripeSubscriptionId,
|
|
status: state.status,
|
|
plan: state.plan,
|
|
current_period_end: state.currentPeriodEnd,
|
|
updated_at: new Date().toISOString(),
|
|
},
|
|
{ onConflict: 'company_id' },
|
|
)
|
|
|
|
if (statusGrantsAccess(state.status)) {
|
|
// Grant a few days past the period end so a brief renewal-webhook delay
|
|
// never flips a paying customer to blocked.
|
|
const expiresAt = state.currentPeriodEnd
|
|
? new Date(new Date(state.currentPeriodEnd).getTime() + 3 * 24 * 3600 * 1000).toISOString()
|
|
: null
|
|
const rows = PAID_CAPABILITIES.map((key) => ({
|
|
company_id: state.companyId,
|
|
capability_key: key,
|
|
source: 'stripe',
|
|
expires_at: expiresAt,
|
|
}))
|
|
await supabase
|
|
.from('capability_grants')
|
|
.upsert(rows, { onConflict: 'company_id,team_id,capability_key,source' })
|
|
} else {
|
|
// Freeze-and-retain: drop only the stripe grants. Trial/comp grants (if any)
|
|
// are untouched; data and tokens are never deleted.
|
|
//
|
|
// multi_user is the one exception to the delete: its 20-day grace window
|
|
// hangs on "the newest grant EXPIRED less than 20 days ago"
|
|
// (lib/entitlements/multi-user-state.ts), so a deleted row would freeze a
|
|
// churned payer's non-owner members instantly, with no countdown banner
|
|
// and no owner mail. Expiring the row NOW anchors the grace exactly at
|
|
// the cancellation, and the grace cron's start-mail window picks it up.
|
|
// Only a still-active row is expired: a re-delivered cancel event days
|
|
// later must not slide the grace anchor (and the mail window) forward.
|
|
await supabase
|
|
.from('capability_grants')
|
|
.delete()
|
|
.eq('company_id', state.companyId)
|
|
.eq('source', 'stripe')
|
|
.neq('capability_key', CAPABILITY.multi_user)
|
|
await supabase
|
|
.from('capability_grants')
|
|
.update({ expires_at: new Date().toISOString() })
|
|
.eq('company_id', state.companyId)
|
|
.eq('source', 'stripe')
|
|
.eq('capability_key', CAPABILITY.multi_user)
|
|
.or(`expires_at.is.null,expires_at.gt.${new Date().toISOString()}`)
|
|
}
|
|
}
|
|
|
|
async function companyIdForCustomer(
|
|
supabase: SupabaseClient,
|
|
customerId: string,
|
|
): Promise<string | null> {
|
|
const { data } = await supabase
|
|
.from('company_subscriptions')
|
|
.select('company_id')
|
|
.eq('stripe_customer_id', customerId)
|
|
.maybeSingle()
|
|
return (data as { company_id: string } | null)?.company_id ?? null
|
|
}
|
|
|
|
/**
|
|
* Route a verified Stripe event to a state reconciliation. Only subscription
|
|
* lifecycle events matter; everything else is a no-op (already ack'd 200).
|
|
*/
|
|
export async function handleStripeEvent(
|
|
supabase: SupabaseClient,
|
|
stripe: Stripe,
|
|
event: Stripe.Event,
|
|
): Promise<void> {
|
|
switch (event.type) {
|
|
case 'checkout.session.completed': {
|
|
const session = event.data.object as Stripe.Checkout.Session
|
|
if (session.mode !== 'subscription' || !session.subscription) return
|
|
const sub = await stripe.subscriptions.retrieve(session.subscription as string)
|
|
const companyId =
|
|
session.metadata?.company_id ??
|
|
session.client_reference_id ??
|
|
sub.metadata?.company_id ??
|
|
null
|
|
if (companyId) await applySubscriptionState(supabase, subscriptionToState(sub, companyId))
|
|
return
|
|
}
|
|
case 'customer.subscription.created':
|
|
case 'customer.subscription.updated':
|
|
case 'customer.subscription.deleted': {
|
|
const sub = event.data.object as Stripe.Subscription
|
|
const companyId =
|
|
sub.metadata?.company_id ??
|
|
(await companyIdForCustomer(supabase, typeof sub.customer === 'string' ? sub.customer : sub.customer.id))
|
|
if (companyId) await applySubscriptionState(supabase, subscriptionToState(sub, companyId))
|
|
return
|
|
}
|
|
default:
|
|
// invoice.payment_failed etc.: Stripe also emits subscription.updated
|
|
// (-> past_due / canceled), which the cases above handle. No-op here.
|
|
return
|
|
}
|
|
}
|