Recurring products and subscription models
Use subscriptions when the customer should approve an ongoing billing relationship rather than a one-off payment.
Recurring billing in Radom is usually built from products plus a customer-facing collection surface such as hosted checkout or payment links. The product defines what is being sold and how it should bill. The collection flow handles customer approval and payment collection.
Common recurring models
Fixed recurring billing
Use this when the customer should pay the same amount on a regular cadence such as monthly, quarterly, or yearly.
Typical examples:
- Software plans
- Memberships
- Retainers
Quantity or seat-based billing
Use this when the customer is still on a recurring plan, but the amount depends on a quantity you control in your own product or operations workflow.
Typical examples:
- Seat-based subscriptions
- Usage tier packages
- Operational plans tied to a customer size band
Usage-based or metered billing
Use this when the customer should be charged according to measured usage rather than a fixed recurring amount.
Typical examples:
- API usage
- Transaction-based billing
- Service usage tracked during a billing cycle
Base plan plus overage
Use this when the customer has a recurring base fee and can incur additional usage charges above an included amount.
Typical examples:
- Platform plans with included volume
- Subscription bundles with extra unit charges
- Monthly commitments with overage settlement
What to confirm before launch
- Which collection surface should create the customer approval step.
- The billing interval or usage measurement model.
- How you will reconcile subscription state in your own systems.
- Whether you need webhooks for billing lifecycle events before going live.