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.
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.
> 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.
This is definitely not ideal.
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.
Maybe Z is tax. Maybe Z is shipping for a monthly package subscription.
Now Understoodit can keep their 3 + 3 plans. +1 to this.
People are sure piling on OP for mentioning taxes -- I think you are all interpreting his request as "Stripe, please add tax calculation" but he's only asking for an additional charges field so he can track his subscriptions + taxes instead of his subscriptions with taxes.
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.
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??"
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.
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.
(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.)
It's funny how different countries and cultures have different views over the same thing. I'm not sure about Canada, but in the US taxes are added on top of each purchase so you advertise a price of 14USD and end up charging X% on top of that price.
If I understood your suggestion correctly people dealing with these problems should do like we do here in Brazil: use the taxes to compose the final price so if I have a product that I want to sell for, let´s say, 10USD and will cost me an average 10% in taxes I would advertise it for 11USD and just deal with the taxes problem internally in my app and not by creating N different plans on the payment processor.
This probably would've been the best idea really. And at the end of the day, if revenue grows at a break neck pace you can always swap out Stripe for something like Recurly.
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"
If they support coupons, I don't see why they can't support taxes. Taxes are just the opposite of coupons and should be relatively easy for them to implement.
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.
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.
Indeed, and that is what we're doing right now. However, it would be nice if they dealt with creating nicely formatted invoices and emailed them so we don't have to.
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.
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.
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.
...And the fact that Stripe doesn't generate and email out PDF invoices FOR YOU? Common now.
[+] [-] peteforde|13 years ago|reply
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.
[+] [-] jd|13 years ago|reply
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.
[+] [-] adrr|13 years ago|reply
[+] [-] robmclarty|13 years ago|reply
[+] [-] shazow|13 years ago|reply
> 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.
This is definitely not ideal.
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.
Maybe Z is tax. Maybe Z is shipping for a monthly package subscription.
Now Understoodit can keep their 3 + 3 plans. +1 to this.
[+] [-] bkorte|13 years ago|reply
People are sure piling on OP for mentioning taxes -- I think you are all interpreting his request as "Stripe, please add tax calculation" but he's only asking for an additional charges field so he can track his subscriptions + taxes instead of his subscriptions with taxes.
[+] [-] the_bear|13 years ago|reply
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.
[+] [-] richardlblair|13 years ago|reply
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.
Would it be a useful feature? Sure. Is it worth taking the time to write about? Hell no.
[+] [-] macspoofing|13 years ago|reply
He's not complaining, he's giving feedback and his wishlist.
[+] [-] JimmaDaRustla|13 years ago|reply
Multiply that by your regional settings and you got some nice bloat.
[+] [-] Bakkot|13 years ago|reply
(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.)
[+] [-] tucaz|13 years ago|reply
If I understood your suggestion correctly people dealing with these problems should do like we do here in Brazil: use the taxes to compose the final price so if I have a product that I want to sell for, let´s say, 10USD and will cost me an average 10% in taxes I would advertise it for 11USD and just deal with the taxes problem internally in my app and not by creating N different plans on the payment processor.
[+] [-] jarek|13 years ago|reply
Sales tax varies from 5% to 15.5%, but only 11% of the country by population (Alberta and the territories) are at 5%, and majority are at 12 to 15%.
[+] [-] psycr|13 years ago|reply
[+] [-] jusben1369|13 years ago|reply
[+] [-] liamk|13 years ago|reply
[+] [-] anujkk|13 years ago|reply
[+] [-] phatbyte|13 years ago|reply
[+] [-] jQueryIsAwesome|13 years ago|reply
[+] [-] otakucode|13 years ago|reply
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.
[+] [-] frankdenbow|13 years ago|reply
[+] [-] sudonim|13 years ago|reply
Consume a stripe webhook / send an email:
http://dl.dropbox.com/u/2454/Slingshot/Pictures/Customer.io-...
Nicely formatted:
http://dl.dropbox.com/u/2454/Slingshot/Pictures/Customer.io-...
[+] [-] liamk|13 years ago|reply
[+] [-] misshap|13 years ago|reply
[+] [-] scrame|13 years ago|reply
[+] [-] Bockit|13 years ago|reply
[+] [-] loceng|13 years ago|reply
[+] [-] Kluny|13 years ago|reply
[+] [-] JimmaDaRustla|13 years ago|reply
[+] [-] nckbz|13 years ago|reply
...And the fact that Stripe doesn't generate and email out PDF invoices FOR YOU? Common now.
[+] [-] ru_nj|13 years ago|reply
[deleted]