I'll throw in one vote for writing your own billing system if possible. It doesn't have to be complex if you're not dealing with an existing legacy system or re

I'll throw in one vote for writing your own billing system if possible. It doesn't have to be complex if you're not dealing with an existing legacy system or regulated industry. I process over $500K/year of SaaS subscriptions with basically just this: * An accounts table with a paid_through column to identify when each person should next be billed * A payments table into which you insert one row per payment for accounting/metrics * A website form that submits to https://spreedly.com/ https://spreedly.com/ to tokenize payment information; the token is all you store * A 100-line cron job that selects all the accounts whose paid_through date is in the past, then charges their subscription against their payment token, sends receipts or dunning mails depending on whether the charge went through, and updates the paid_through dates Coupons, discounts, etc can be accommodated just by adding some columns and tweaking the billing script's SQL query. The payments table is sufficient information to calculate all the valuable SaaS metrics from your database as well -- CLTV, MRR/ARR, churn rate, etc. Integrating with Spreedly instead of directly with a payment provider means you can change processors without changing any code -- your choice of payment processor becomes just another token.