Billing, Subscriptions, and Entitlements
Plan access, provider state, usage ledgers, invoices, cancellation, and reconciliation
Plans, Subscriptions, and Entitlements
A plan is an offer, subscription a customer agreement, entitlement a permission, and payment a financial event.
How to apply it
Centralize entitlement evaluation using plan, subscription status, trial, add-ons, seats, grace period, and overrides. Define behavior for trialing, active, past due, paused, canceled, and incomplete states.
Worked example
A central feature-entitlement service resolves access to audit exports rather than repeating plan-name checks across controllers.
Common mistakes to avoid
Scattering plan conditionals or treating a checkout return URL as proof of payment.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
- A plan is an offer, subscription a customer agreement, entitlement a permission, and payment a financial event.
- Centralize entitlement evaluation using plan, subscription status, trial, add-ons, seats, grace period, and overrides.
What is the strongest production practice for Plans, Subscriptions, and Entitlements?
Payment Provider Integration
Use hosted checkout or approved provider SDKs; create sessions server-side with trusted price IDs and customer context.
How to apply it
Verify signatures, deduplicate event IDs, process state transitions idempotently, and reconcile internal state with provider records. Events may be duplicated, delayed, or out of order. Never store raw card data.
Worked example
After checkout redirect, show pending status until verified provider state confirms the subscription.
Common mistakes to avoid
Granting paid access from an unverified browser redirect or blindly overwriting state from an old event.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
A browser redirect is not proof of payment. Use verified provider events and server-side reconciliation before granting paid entitlements.
- Use hosted checkout or approved provider SDKs; create sessions server-side with trusted price IDs and customer context.
- Verify signatures, deduplicate event IDs, process state transitions idempotently, and reconcile internal state with provider records.
What is the strongest production practice for Payment Provider Integration?
Usage, Invoices, and Cancellation
Define the billable event, event time, billing boundary, correction rules, and treatment of late-arriving usage.
How to apply it
Store immutable usage events with tenant, metric, quantity, timestamp, and idempotency key. Snapshot invoice prices and line items. Define proration, refunds, tax handling, failed payments, cancellation timing, data access, and deletion schedules.
Worked example
A unique organization-and-event key prevents retrying the same usage event from double-counting it.
Common mistakes to avoid
Incrementing counters without auditability or silently changing the meaning of a billable unit.
Practice task
Implement this concept in the capstone. Add one positive test, one negative or failure-path test, and a short note explaining the trade-off you chose.
- Define the billable event, event time, billing boundary, correction rules, and treatment of late-arriving usage.
- Store immutable usage events with tenant, metric, quantity, timestamp, and idempotency key.
What is the strongest production practice for Usage, Invoices, and Cancellation?