Files
accounted/lib/stripe/subscription-sync.ts
T
Mattsson aabddb592f feat(billing): multi-user paywall: multi_user capability, 20-day grace, owner-only dormancy (#2099)
* 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>
2026-09-01 11:29:12 +02:00

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
}
}