I'm sympathetic to Liam's grief with calculating taxes, and handling the edge cases of people moving around different tax zones. It's not exclusive to Canada, of course.
However, my perspective is that Stripe sits one level lower on the infrastructure map than a service like Recurly (http://recurly.com) which is designed to abstract the pain of subscription management away from app developers. I use Stripe first and foremost as a best-in-class one-time payment processor. There's nothing stopping me from building a subscription management solution on top of Stripe; I'd just be re-inventing the wheel.
Stripe's subscriptions strike me as a good compromise between nothing at all and something that becomes more sophisticated over time. If they try to stamp out all of those edge cases, they will inevitably break someone else's application that relies on a slightly different interpretation of "the way things are supposed to be".
I sincerely hope that Stripe continues to say No to feature requests far into the future. Where does PDF invoice generation (with HTML templates of course) fit into "the simplest thing that works"? When Stripe notifies you of a sale, generate your own invoice. Maybe even consider open-sourcing that code. Adding it to Stripe is not the best thing to do.
Exactly. Stripe can't support every bit of functionality out of the box, because then the API would get really convoluted. Just think about what sort of discounts are commonly use: absolute discounts, percentage discounts, coupon codes with expiration dates, conditional coupon codes, bulk discounts, discounts that only apply for the first month. And so on. When dealing with billing logic there is a tremendous amount of accidental complexity.
Stripe offers a low-level API and a higher level API and framework can be built on top of that. So what we really need are some high-quality django/rails modules that deal with all the mundane bookkeeping. Then you can easily fork the module to make adjustments where needed.
Recurly doesn't support sales tax(tax rate varies by location) as well. Easiest solution for both providers is to generate an invoice item called "Taxes" and add it for each bill cycle. There are many SaaS tax providers out there.
I agree. I completed a similar e-commerce app for a client in Canada and, honestly, it wasn't too hard to make 13 optional, client-editable, tax percent values that get tacked on to an order before being sent for payment processing. Just takes a bit of elbow grease. I like, as a feature, that Stripe doesn't impose itself on how I want to implement payments in my app.