Use an established billing provider, not custom logic
Stripe Billing or an equivalent handles the regulated, error-prone parts (card storage, PCI compliance, retry logic) — building this from scratch is both unnecessary risk and wasted engineering time.
Plan tiers and usage limits
Deciding what's gated by tier (features, usage caps, seats) is a product decision made before implementation — see How to Add AI to a SaaS Product for how AI features specifically fit into this.
Upgrades, downgrades and proration
Mid-cycle plan changes need clear proration rules — established billing providers handle the calculation, but the business rules (can a customer downgrade mid-cycle? what happens to unused credit?) still need deciding.
Failed payments and dunning
A defined retry schedule and account-status handling (grace period, feature restriction, eventual suspension) for failed payments — this needs to be an explicit decision, not left to default provider behavior without review.
Whose payment account?
The business should be the account holder with the billing provider, and the developer an invited user with only the access the work needs. An account opened in a developer's name is hard to move later and ties your revenue to their login. Keep this practical: check who owns the account, who can change payout details, and who holds the recovery route. Do not share passwords; use invitations. Confirm any compliance or verification questions with the provider and your own adviser.
Questions
Should we build custom payment processing?+
No — use an established provider (Stripe Billing or equivalent) for the regulated, error-prone parts; focus your own effort on the product logic around it.
What happens when a customer's card is declined?+
A defined retry schedule and grace period, then account restriction — designed explicitly, not left to default behavior unreviewed.
Can pricing tiers change after launch?+
Yes, but existing customers' grandfathering needs an explicit policy — decide this before it becomes a support problem.