Roll your own. Start with a subscription table with a paid_through column, and a payment table for recordkeeping. Your billing code is a daily cron job running a single simple script, that selects all rows with paid_through less than current date, charges each user's card on file, and updates the two tables. Discounts, different subscription terms, receipts, dunning mails are all simple additions to the daily billing script that you can add as you grow.

This has worked for me with tens of thousands of customers and millions in billings, and I've never had to worry about being locked into some payment company's proprietary system. Whatever pricing scheme you initially come up with for your app probably won't be right. You might have 6 plans when you only need 2. You might find out you were charging a flat monthly rate when you really need to be charging per widget or per user or per server. The more you rely on someone else running your billing, the harder it will be to experiment and find the right way to do billing for your customers.

You can avoid being locked in to a payment processor for storing and charging payment info too. I use Spreedly (https://www.spreedly.com) which provides payment card tokenization and a single unified API for over 100 payment gateways. I can use Braintree today, Stripe tomorrow and ShinyPaymentStartup next year without changing any code or re-collecting billing info from customers.