Stripe Would Be Perfect If...

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.<p>However, my perspective is that Stripe sits one level lower on the infrastructure map than a service like Recurly (<a href="http://recurly.com" rel="nofollow">http://recurly.com</a>) 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.<p>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".<p>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.

Everyone is piling on the "stop trying to feature-creep Stripe!" wagon but there is at least one reasonable suggestion in this post: A per-user fee tacked onto an existing plan.<p>&#62; In total there are 4 different tax rates and then no taxes for international customers, for a total of 5 different tax levels. We currently have 3 monthly plans, and their 3 yearly equivalents. This means that we had to create (3 + 3) x 5 = 30 plans within Stripe.<p>This is definitely not ideal.<p>Agreed with everyone that asking Stripe to take care of figuring out the tax rates is far too much, but being able to say "Subscribe customer X to plan Y," which already exists, "and in addition add a Z fee to each charge." Z could be a percentage or an absolute value.<p>Maybe Z is tax. Maybe Z is shipping for a monthly package subscription.<p>Now Understoodit can keep their 3 + 3 plans. +1 to this.

Every time I sign up for a service and receive an email from recurly (or similar services), my first thought is, "this company doesn't care about user experience if they're trusting recurly to send me important communications." The email content is always generic and cold, and it's particularly unimpressive when I sign up for a free trial and receive a "thanks for subscribing" email telling me that I was successfully billed $0.00.<p>I'm glad that Stripe keeps their hands off my invoices. You could argue that Stripe could just let me turn that feature off, but Stripe understands that their customers are 100% responsible for the end-user experience, and I respect their decision not to get involved in that at all.

When I read this article I honestly thought to myself "Are you kidding me??"<p>Stripe makes receiving payments incredibly easy; easier than it has ever been before. Yet, somehow you complain that you need to deal with edge cases? There will always be edge cases... if your biggest issue in dealing with payments is handling taxes then I would say you are doing alright.<p>Would it be a useful feature? Sure. Is it worth taking the time to write about? Hell no.

It seems to me that creating several dozen subscription plans on Stripe is indicative of a deeper problem: that you have several dozen different prices consumers end up paying. How about instead you advertise the prices that consumers will actually have to pay? Bump up all of your prices across the board by the expected cost of taxes to even out the cost.<p>(Unless there's some law about not charging consumers in different provinces a different pre-tax cost, or some province charges so much tax that to make other provinces eat a share of that cost would be unreasonable.)

This is a good write up. This is a challenge for Stripe though. They're a payment gateway that can manage recurring payments. Things like taxes and invoices are usually supported by additional applications that run on top of a payment gateway. Edge cases too. So I'm sure they're there saying "Where do we draw the line between where we end and other offerings/services begin"

... available worldwide.

I can entirely understand why Stripe doesn't deal with taxes. They're insane. I was involved in implementing a site that sold off-site discount parking reservations near airports and dealing with taxes was certainly no fun. And this was restricted just to the US. There is a national consortium of states that makes getting state sales tax slightly easy.... but all the services that offer the ability to look up tax rates didn't cover the service we were offering, parking reservation. So we had to investigate the rates ourselves... and it's a good thing we did. Some counties or municipalities have created special taxes to apply specifically to this kind of service in order to make things more expensive so that parking at the airport isn't such a terrible deal.... oh and those laws don't stay static, of course. You have to keep on top of them, and modify your code/data/whatever when new laws take effect or old laws are repealed.<p>The most fun was when an area in Texas passed one of these laws taxing parking near airports (even if that parking is offered by a hotel or some other established business... if it has shuttle service to the airport, it must be taxed) but all the various people offering parking through our site didn't want to comply with the law, so they wanted us to not charge the tax to customers! Worse, the business types wanted to actually cater to these scofflaws. I refused to implement it though, because that's just stupid. We'll collect the tax, if the clients don't want to actually pay the municipality, that's their business... but we do have to keep track of who charges it, how much, when those rates change, etc... it's a a bit of a pain, and even the services dedicated to tracking this kind of stuff are not comprehensive.

You can make invoices by using their webhooks (<a href="https://stripe.com/docs/webhooks" rel="nofollow">https://stripe.com/docs/webhooks</a>). Just email your customers when a billing event occurs

I'd also agree that dealing with taxes on Stripe is much more complex than it should be. It could be that there is no way to simulate time. It would be nice to see how Stripe reacts after one month subscriptions, or at least a few days, to get a real sense of how pro-rated prices are calculated in practice. I'd also like to see a better way to test webhooks in two cases: 1. when they are not successful and 2. be able to test webhooks with your application specific parameters.

The author is not suggesting that Stripe handle taxes, he is suggesting that Stripe have an option within plans to handle different tax rates, rather than having to create a separate plan for each district that has a different tax rate, and the ability to have that calculated in to the total charge.

I quite like the suggestion at the end of the article, that there may be benefit taking some user-centric design methodologies and applying them to API design. I wonder if there are any APIs that already do this and what the general consensus is on their perceived quality.

Great writeup. Hopefully they will implement all of this before the time I need to use Stripe (still planning to at this point anyhow).

The diagram is really helpful, thanks. I'm currently trying to use Stripe in a school project about REST APIs, and it helped make the concept more concrete in my mind.

Who's the picture of the guy in the banner? It doesn't look like "High Expectations Asian Father"...

I feel this is more a case of poor user experience. This is a company who couldn't mark their service up 10-20% to account for taxes and a unified price.<p>...And the fact that Stripe doesn't generate and email out PDF invoices FOR YOU? Common now.