00 · SIEM subscription: multi-gateway dumb pipe (working tree, 14 Oct 2026) Diagram

scripts/stripe-cutover.ts export runs before the schema push: it saves each Stripe subscription's status, paid-through period and legacy invoice and payment IDs, then cancels the Stripe subscription with no proration and no final invoice.
apply runs after the push and seeds: Stripe active becomes ACTIVE until its paid-through date, past_due or unpaid becomes PAST_DUE with grace; prices come from the seeded plan rates in the subscription's own currency; legacy IDs are copied into externalId/provider; the customer is emailed to add a card, and the first card becomes the default.
seed:subscription-countries defaults a missing owner country to IN and writes the gateway and currency with it.

Workers and services write status through subscriptionRepository.updateStatus; PaymentEventProcessor calls validateStatusTransition and writes status inside its settlement transaction. Admin activation uses a conditional PENDING_SETUP update; concurrent activation cannot advance the cycle twice. Its rollback (first renewal could not be scheduled) writes PENDING_SETUP back without the transition check, and updateById accepts a status field without the check.
Abandoned-cleanup deletes UNPAID/PAYMENT_FAILED rows older than 25h that have no coupon, no signup payment in flight and a provider; a Razorpay signup is kept while its order can still be paid (late authorisation up to 3 days) and settled if it was; deletion is separate from status transitions
SubscriptionService, billing workers and sub-finalization also use the gate; their gate arrows are omitted for readability
The map allows PENDING_SETUP → ENDED: unused free trials end at the claim deadline, then expire after 7 days. A paid trial conversion goes TRIALING or ENDED → ACTIVE; a CANCELLED subscription that is renewed and paid goes → ACTIVE. The PAID status no longer exists.

Company registration country: IN → Razorpay INR; every other supported country → Stripe USD. Fixed per subscription.
Plan rate columns per currency; one interval discount % and one tax % shared by both, baked into the rate: every price is tax-inclusive and the server never adds tax
Each Payment stores amountUsd + amountInr at capture (fxRate.ts, Redis 1h cache)
Dashboard sums stored legs; a separate card shows native USD and INR totals
Access follows the current subscription's real status through one rule (subscriptionAccess.ts): SIEM only while ACTIVE or TRIALING; team, profile, subscription and wallet view in PENDING_SETUP, PAST_DUE, PENDING_REAUTH, CANCELLED and ENDED; profile and subscription only for UNPAID, PAYMENT_FAILED, EXPIRED or none. The server route gate, the IAM context and the client route guard all read it.
The User registration country and phone timezone do not choose billing. Subscription country/provider/currency cannot be edited after creation.

The customer selects one discount (quote, a running promotion, or a coupon code); nothing stacks. A coupon code reserves its slot when applied; the selection lives 35 minutes per action (24 hours at most) and an ended discount falls back at checkout. The slot is redeemed only after first settlement (D11).
Fixed discounts require INR or USD and apply only in that currency; percentages have no currency
Quote links identify one custom plan; customer API excludes unrelated custom plans. QUOTE coupons expire after 7 days; quote becomes ACCEPTED in the first successful settlement transaction (D48).
Price push is plan-wide only, by a super admin, via the price-push queue: one job per subscriber with a fixed ID. It stages pendingPriceAmount from the first renewal at least 24 hours after the customer's email is recorded; applied after that cycle's successful charge; Razorpay ceiling gate → PENDING_REAUTH. A plan change prices itself and discards a stale queued push.
A plan change is priced by one server rule (quotePlanChange) from what the customer pays; the discount follows the new price (percentage recomputed, fixed kept). Fewer assets than onboarded agents asks which to keep; removed agents leave the portal and admins are emailed to remove them from the SIEM server by hand.

billing-cycle (attempts 1), retry-payment (max 3, 3-day cadence, temporary failures only, next attempt scheduled by the failure webhook), price-push-jobs (plan-wide pushes), email-jobs (7/3/1-day reminders rendered when sent), lifecycle (trial-ending, grace-warning, final-deactivation, mandate reminders; attempts 3)
Redis charge lock: one charge in flight per subscription; Razorpay also persists a unique attempt per cycle across retry keys, so an uncertain Razorpay debit blocks another debit. A Stripe charge with an unknown outcome keeps the lock and is reconciled by resending the same request with the same idempotency key (D54 resolved).
grace-start job exists but is never scheduled (scheduleGraceStartJob has no caller)
Repeatable: 00:00 sub-finalization, 00:15 abandoned-cleanup, 02:30 maintenance, 03:00 reminder-sync
Webhooks: POST /api/v1/subscription/webhook/stripe and /razorpay (server.ts L76-107)
Every minute: indexed coupon expiry and pending settlement follow-up scans, batches of 100; gateway calls outside database transactions.