Customer Segmentation

Account type determines dunning thresholds, payment method enforcement, and access revocation rules. A $50 failed invoice kills a free account but escalates to finance for enterprise.

Account type is determined from subs_account table's account_type column (enum). Set during onboarding or manual override. Also synced to Stripe customer metadata as account_type tag.

The current system uses binary flags — skip dunning or don't. An expired card and six months of non-payment can get the same treatment. The brain enables per-type rules based on account context. Not skipping, but different consequences per account type.

Enterprise accounts are multi-seat, net-30 or net-60 terms, with dedicated account managers. Typically $10K+ ARR. Invoice-based billing, not Stripe subscriptions. No auto-cancellation.

Partner accounts are commission-based with revenue-share model. Portal access instead of dashboard. Bulk licensing of zones or products. No per-customer subscription visibility.

Sponsored accounts are funded entirely by Cloudflare credit (internal grants, hackathons, employee accounts). No subscription. Credit balance drives access. Access revokes when credit exhausted, not via dunning.

China accounts are a separate legal entity, compliance-gated. Payment methods restricted to Alipay and WeChat Pay. No PayPal. Billing in CNY, not USD. Customer data residency restrictions apply.

Standard PayGo accounts — the default dunning path. Core retry logic, automatic escalation, standard thresholds.

Active investigation: what account types exist in production? Known: Contract, PayGo partner, Enterprise legacy, PayGo, Startup. Others TBD. Gates segment rules.

Product team must provide the complete list of account types in production.

Per-type dunning treatment is a business rule, not just an engineering decision. Product and finance must sign off on what happens at each escalation stage for each account type.