Question 1

How do you calculate proration for a mid-cycle plan upgrade?

Accepted Answer

Proration credits the unused portion of the current plan and charges for the new plan from today until the current period end. Formula: days_remaining = (current_period_end - today).days. days_in_period = (current_period_end - current_period_start).days. credit = old_plan_price * (days_remaining / days_in_period). charge = new_plan_price * (days_remaining / days_in_period). net_charge = charge - credit. Round both to the nearest cent before subtracting to avoid floating-point errors. Always use integer cents: credit_cents = old_price_cents * days_remaining // days_in_period (integer division). Create two InvoiceItems: a negative one (credit) and a positive one (charge). Net immediately (charge the difference now) or add to the next invoice (simpler but the customer gets a windfall on the upgrade date). Stripe prorates and creates an invoice immediately; the customer is charged the net difference.

Question 2

How does the dunning process reduce involuntary churn from failed payments?

Accepted Answer

Involuntary churn: subscriptions cancelled not because the customer chose to leave, but because their payment failed (expired card, insufficient funds, bank fraud hold). Dunning reduces this by: (1) Retry schedule: attempt payment on day 1, 3, 7, 14 after failure. Exponential spacing avoids repeatedly triggering fraud detection. (2) Smart retry timing: analyze historical data -- payments from a specific bank succeed more on paydays (1st and 15th of month). Time retries accordingly. (3) Card updater: Visa and Mastercard provide a card updater service -- automatically update card numbers when a card is re-issued. Reduces "card expired" failures by 40-60%. (4) Dunning emails: send a friendly reminder with a payment update link. A magic link (authenticated, no login required) reduces friction. (5) Grace period: give customers a 14-day grace period in PAST_DUE status before cancelling -- many customers update their payment within a week.

Question 3

How do you handle taxes across different jurisdictions for SaaS subscriptions?

Accepted Answer

Sales tax for SaaS varies dramatically by jurisdiction: US states have different rates and nexus rules; EU VAT applies where the customer is located (not the seller) for digital services; some countries have no tax on software. Approach: never hardcode tax rates -- they change frequently. Use a tax calculation service (Avalara, TaxJar, Stripe Tax). On invoice creation: call the tax service with customer address, product type, and amount. The service returns the applicable tax rate and the computed tax amount. Store the tax breakdown on the InvoiceItem. For VAT: collect the customer's VAT number and store it on their account. Apply reverse charge mechanism for B2B EU transactions (no VAT charged, customer self-reports). For US nexus: you only collect sales tax in states where you have "economic nexus" (typically > $100K in sales or > 200 transactions per state per year). Track nexus exposure per state.

Question 4

How do you implement annual plan billing with a monthly equivalent display price?

Accepted Answer

Annual plans are often sold as "$10/month billed annually" ($120/year). The billing cycle is annual but the displayed price is monthly. Implementation: store the plan with billing_cycle=ANNUAL and price_cents=12000 (total annual price). Display: price_cents / 12 = $10/month equivalent. On subscription creation: charge the full $120 immediately. Create an invoice for $120, covering the entire year. current_period_end = current_period_start + 365 days. Proration for downgrades: if the customer cancels mid-year and is due a refund: refund_amount = plan_price * (days_remaining / 365). Store period_start and period_end on the subscription for accurate proration calculations. Renewal reminder: send an email 30 days before the annual renewal date. Many customers forget they signed up annually -- this reduces dispute chargebacks at renewal.

Question 5

How do you design a metered billing system that handles high-frequency usage events?

Accepted Answer

Usage events (API calls, storage reads, message sends) can arrive at millions per second. You cannot query the raw events table to compute each invoice -- too slow. Two-layer approach: (1) Real-time aggregation: ingest usage events into a Kafka topic. A stream processor (Flink or Kafka Streams) aggregates events by (subscription_id, metric, hour). Write hourly rollups to a metering_rollups table: (subscription_id, metric, hour, total_quantity). This reduces millions of raw events to thousands of hourly summaries. (2) Invoice generation: at period end, SELECT SUM(total_quantity) FROM metering_rollups WHERE subscription_id=X AND metric=Y AND hour BETWEEN period_start AND period_end. Apply pricing tiers. Create InvoiceItems per tier. Real-time usage API: customers can query their current usage: SELECT SUM(total_quantity) FROM metering_rollups WHERE subscription_id=X AND hour >= period_start. Respond in < 100ms.

Low-Level Design: Subscription Billing — Recurring Charges, Proration, and Dunning Management

Core Entities

Subscription Lifecycle

Proration Logic

Dunning Management

Metered / Usage-Based Billing

Revenue Recognition