Hi folks -- as Edwin points out elsewhere in the thread, the article title isn't accurate. (I'll update or delete my comment if it's fixed.)
[Update: it was changed. It used to read "Stripe is now charging 0.5% more for recurring charges."]
You can happily make recurring charges yourself and no additional fees are incurred. Lots of Stripe customers do this and we don't charge anything extra for it.
If you decide to use Stripe Billing, which is a separate product, we charge for that. Stripe Billing's pricing hasn't changed in a few years. What's changing is that we're ending the several-year grace period where we didn't charge anything for Stripe Billing for businesses who started to use this functionality before 2018.
Charging for Billing helps us fund a lot more investment in it -- we've gone from very basic cron-like functionality to a pretty full-featured subscriptions management tool. (You can read more at https://stripe.com/billing.) Billing is now sophisticated enough that companies like Slack and Atlassian are using and paying for it. We've built things like "Smart Dunning" (which improves revenue recovery for failed charges by about 14%), better analytics, international payment method and invoicing support, and a whole host of other features. There are now more than 30 people working on improving Billing.
Importantly, Stripe Billing is (and will remain) significantly cheaper than most of the other competitors in the space.
I feel that spinning this as a several-year grace period is a bit disingenuous. I'm a huge Stripe fan, but this is leaving a bad taste in my mouth. Here's the exact notification that went out on April 6, 2018 in the dashboard:
"As a user of Stripe Subscriptions, you will get all the functionality of Stripe Billing's starter plan with no change in price. You can continue using it free of charge on your existing Stripe pricing, even beyond the $1M free threshold. This will be automatically applied to your account. Contact support@stripe.come with any pricing questions"
As far as I can see, the Billing Starter plan has not changed and still applies. Not only that, it claims we get "all the functionality of Stripe Billing.." when this hasn't been the case for a few months. New features have been gated recently, ie. the new customer portal.
You have every right to change your pricing how you see fit. However, if this message was worded as it being a grace period, we would have taken steps two years ago to consider other tools or building something in-house.
You're right. It would have been a lot better if we'd made explicit that we weren't intending to make a permanent commitment. This is good feedback for the next time we do something like this.
(Our actual thinking was that we'd iterate on the product for a few years until we were confident it was good and worth paying for -- with both large and small companies using and paying for it -- and then revisit.)
You're welcome; appreciate the response. For what its worth, I have yet to get an email about the increase and HN is the first I've heard of it.
I should have known something was up when Stripe sent out the email survey two days ago about subscription pricing. Very strange that you only sat on those results for a day before pulling the trigger on this. Interestingly, some of the survey answers included concepts of a free tier.
To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower.
> To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower.
While this is true on some level, the challenge is that we'd have to set pricing at an inefficient point (i.e. we'd end up charging more than some businesses can afford to pay and less than others are willing to pay). If we charged $1/sub/mo (say), $5/mo subscriptions would be prohibitively expensive. At the other extreme, if we charged $0.02/sub/mo per month, it just wouldn't make sense to invest as much in improving the product, which would indirectly hurt businesses by depriving them of a counterfactual product that they'd like to be able to buy. Pricing is obviously always an exercise in trying to find a reasonable trade-off between simplicity / optimality and this is our best effort.
Would you be willing to consider capping the per-subscription cost? For instance, "0.5% of your subscription price, at most $x/month/subscription"? That would keep it reasonable for low-cost subscriptions, and have high-cost subscriptions pay more, but the cap would make it feel much more reasonable to use Stripe Billing even for very large subscription costs.
With a structure like that, I'd want to use Stripe Billing for every customer, rather than considering any kind of special arrangements for high-value customers.
You're right; regardless of which model you pick, one side is going to be affected more. I'm sure you ran the math on it and saw Stripe customers skewed closer to the $10/mo sub than the $1,000/mo sub.
In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against?
To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.
> To be honest, none of the new Billing features are relevant to us.
Bingo. This is like your cell phone company telling you that the tethering feature you have always had access to is now part of their Pro plan, for which you won't be charged extra. Then they turn around and start charging for the Pro plan on the grounds that it has a bunch of features you don't care about — and one feature that was previously available outside the Pro plan.
Unless I'm misunderstanding what's happening here, this seems really lousy. I became a Stripe customer because of the simplicity and transparency. It seems that both of those benefits are disappearing.
I may be out of date but thought the 2.9% price was already a premium price vs getting a merchant account/gateway and the Stripe API was the value for which you paid the premium. In which case I’d expect the product features to grow over time without increased pricing. Acting like new revenue is required to grow feature set is a half baked excuse when simple explanation that they intend to further monetize existing features seems more truthful.
Considering the Durbin Amendment capped debit card processing at 0.05% and $0.21 per transaction, and interchange pricing for credit cards ranges from 0.65% to 2.4% plus a few cents for the auth fee, it is pure profiteering that PayPal and Stripe charge this much to process cards.
> In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against?
I'm actually not sure. I'll check with the team. (The timing of the survey was coincidental, though -- we've been working on making our Billing pricing consistent since the start of the year.)
> To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.
We seriously considered that. It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. The fact that such a large fraction of customers we reached out to directly were willing to pay for a more full-featured Billing (mostly on the basis of competitors being significantly more expensive) made us eventually conclude that it wasn't worth the complexity of having two adjacent versions of the product.
Are the code paths really that complicated? If you want it extra simple, code path wise, then on accounts where it's not enabled you could hide the menu/API options for the new stuff and monitor your logs for anything sneaking through. Your actual payment processing backend doesn't even need to know there's a difference in feature set between these customers!
If current Stripe customers wish to switch to another processor like Vantiv, First Data, Chase Paymentech, etc will Stripe enable data migration from your ISO to another ISO?
I did this when moving from a First Data ISO to Vantiv to ensure we could avoid collecting card data from clients again.
When I first signed up with Stripe years ago, it was a breath of fresh air. Stripe did one thing exceedingly well, at an understandable price and took minutes to integrate with.
I could sell Stripe to my developer friends (and did, a lot!) in a single sentence: "You can add credit card charging to your site in about 15 minutes for 2.9% + 30¢ per transaction." I can't do that anymore. Stripe is no longer a single-sentence sell.
Stripe still does good work. But the air is getting murkier. I'll point to some objective changes, but mostly Stripe is just starting to feel different.
- Several years ago, when I saw announcements that Stripe started supporting ACH payments (and later international payments), I thought, "Great! This is Stripe! I'll just be able to flick a switch and turn those on." Not so. I understand that it's complicated from their end. It's just not the same "Stripe is so easy" experience. "Stripe is supposed to abstract away the complexity, not expose it to me."
- The pricing page is a big sign of the added complexity. There used to just be one or two numbers on that page [1]. Compare that with the current pricing page [2]
My suggestion to you, pc: Start a little company within Stripe to disrupt Stripe (i.e. re-simplify) in the same way Stripe disrupted the industry 10 years ago. Or keep getting bigger and become just as complex as the things Stripe replaced.
I agree. I feel like good companies like Stripe want to keep growing. With this, comes the need to increase revenue to cover the extra costs. I don't know if it's investor pressure, or the fear of being stagnant, but some companies are arguably better off the way they are. There's no need to grow at all costs.
If you want more users, double down on marketing to existing users instead of pissing them off. Although it's really hard to measure, happy users do the marketing for you and bring in more customers.
First they started charging for international cards (with the "grandfathering" for years excuse), now this. I've already migrated off of Stripe and now actively recommend people think twice about going with them. Instead, I'm recommending Braintree... aka Paypal. It seems we've come full circle already.
Even more confusing, it's showing me (in NZ) prices in GBP, which I have no use for, and talking about European cards as somehow special. They seem to think currency and language are the same thing (NZ English is pretty close to British English for computer purposes, so it redirects me to en-gb?). But https://stripe.com/en-nz/pricing#pricing-details actually exists! Weird.
Charging one rate for all payments sounds nice. But not all payments cost the same for Stripe. One rate for all customers means that you are breaking even / losing money on some transactions and making money on others. In other words, you're asking some of your customers to subsidize others, because.... it makes the product simpler to sell. Why would anyone agree to the wrong side of that bargain as a customer?
Because it makes the product easier to buy? In the past I could buy stripe and know exactly what my costs were going to be. Looking at the pricing page now it’s a fucking swamp.
If I add all their percentages up I’m paying 10% per transaction.
This is an excellent Suggestion: My suggestion to you, pc: Start a little company within Stripe to disrupt Stripe (i.e. re-simplify) in the same way Stripe disrupted the industry 10 years ago. Or keep getting bigger and become just as complex as the things Stripe replaced.
Kind of agree with cabolos here. When we signed up for Stripe, the fees included access to Strip Subscriptions. We chose Stripe in part because of that. Now we either have to pay more for the same functionality or migrate of.
We'd be totally happy keeping the old functionality of Stripe subscriptions and not getting any of the new hotness. I think Stripe has done a great job supporting old versions of the API, seems like we should just be able to stay on our old pricing / subscriptions functionality as well.
Saying that we can build the infra ourselves to do reoccurring kind of goes against what we purchased Stripe for initially. I know technically you can change your pricing/billing however you want but this is more of "let's capture more revenue from old customers" than it is "we launched a bunch of stuff thats new so pay for the new stuff".
We've been testing this change for a few months to make sure that, broadly speaking, the vast majority of current customers are willing to pay for the new functionality. We don't want to even try to charge for things that customers don't feel they're getting good value from.
There's obviously heterogeneity, though, and we'll be as reasonable as possible. If this would be really disruptive for your business, or if you need more time to plan a migration (if you don't think Billing makes sense for you), or something like that, I'd be happy to connect you with the team -- we could extend your current pricing through the end of 2021.
> We don't want to even try to charge for things that customers don't feel they're getting good value from.
Then presumably you'll follow alooPotato's suggestion and allow folks to not pay extra for stuff we never wanted and never signed up for?
Presumably you can see how many of your customers (myself included) have never even looked at some of these new features you've added to Billing. I'm literally finding out about these features in this thread. If people were not aware of these features, you can figure they are not interested in paying extra for them.
Extending the pricing through 2021 seems reasonable and would give us a chance to do the cost/benefit on upgrading to Stripe Billing (including integration work) or moving off. Thanks for giving us the time to make the right decision for our business.
There have been comments elsewhere in the discussion that for folks with higher volume, we should be negotiating our fees. At what volume would you recommend companies reach out to your team to do so?
I think Stripe does a lot of things right, but your comments back in 2018 certainly indicated that Billing could be used in perpetuity:
"- For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price."
I specifically reached out to Stripe support back then to verify this would be the case and they confirmed. If you've since changed your mind, I think you should come out and say that's the case as opposed to saying this is a communications issue.
Long term Stripe customer across multiple companies here.
I'm ok with paying for services like this that provide loads of value. I expect there's increasing diversity in terms of Stripe's customer base and how they use the product, and trying to pick a single percentage price point that works across all of them is no longer feasible.
That said, I'm quite unhappy with Stripe's pricing as an AU customer. We're paying exorbitant rates to convert USD to AUD (think retail bank rates despite transacting multiple millions a year, ~3x what we'd pay Transferwise). There's no option to settle in USD, and a lot of our expenses are in USD, so we then pay another currency conversion fee when we spend.
It's problematic to the extent that we're considering whether the ongoing costs and hassle of setting up a US entity, dealing with international tax, compliance, parent companies etc. would be worthwhile.
This is infuriating. I've been told so many times that it's 'coming'. 5% of top line revenue is pretty significant and now an added 0.5% feels like a slap in the face.
Braintree have offered it for years so this might be the final motivation to switch over.
It's been around 7 or 8 years with Stripe now and it just seems like they are prioritising heavily increasing their average revenue per user at all costs.
Yep, heard loud and clear. We've been investing a lot in USD (and other currency settlement) in various markets (and actually just released it in Singapore). We're working on it in Australia too.
Do you really need to set up a US entity just to open a US bank account?
If not, I would set up a US checking account and settle some portion stripe transactions there. Take that revenue and pay your US vendors. No currency conversions.
We process a significant amount of charges through Stripe and this is hitting us hard. We’re basically being told that you’d like to keep some of our money for yourself. We were never told that we should expect such a fee increase. This smells a lot like bait and switch.
I'm sorry that it feels that way. Stripe Billing's pricing has been public since 2018. (We didn't charge any of our existing users from the outset precisely because we wanted to avoid any sense that there's a bait-and-switch. We wanted to wait until we really were confident that we had a good product that businesses are willing to pay for.)
I'm sorry that it feels that way. Stripe Billing's pricing has been public since 2018.
But lots of us have been using Stripe for a lot longer than that, and don't necessarily want or need all the extra things you're now putting under the "Billing" brand.
We haven't received any notification of a change from Stripe, but from the HN discussion, it looks like the option to just have a simple, automated recurring charge -- the key feature that attracted businesses like mine to Stripe in the first place -- is being removed. If that is the case then we'll naturally view the change as a 0.5% increase in Stripe's fees, pure and simple.
Second that! We are exactly in the same shoes. We are not using or planning to use any of those extra features and are pretty disappointed by that move. Costs us a couple of grand more every year in stripe fees or we now have to go hire a developer.
FWIW, we're in the UK, where a combination of the European PSD2/SCA changes, ever more complicated tax rules, and uncertainty over Brexit is making the model used by services like Stripe unattractive now. We've been looking into merchant-of-record alternatives, where it can be someone else's problem to keep up with all the tax and regulatory changes and to implement all the awkward UI edge cases. We haven't yet made a final decision on how to proceed, but apparently the difference in fees relative to the existing services we use is going to be smaller in the new year, so that's one barrier to switching getting lower.
Your account has been upgraded to Stripe Billing for free. No matter how much revenue you process on Stripe, you’ll get unlimited use of Billing’s Starter plan included in the price you currently pay for payments. All new features are available in your account now, no API version upgrade necessary.
If Stripe pushed ahead forcing an additional 0.5% with no new features adopted, that's pretty predatory and the kind of rent seeking that will leave a bad taste in a lot of people's mouth which then when starting new projects won't be looking to adopt Stripe with the same passion they did years ago.
Unfortunately no, It was never communicated to us. we were told stripe billing would be free to use. The very least that Stripe needs to do is to grandfather the existing revenue for old customers, and put in the charge for only newly created subscriptions.
Those are reference customers and should be treated with much greater privilege. They are early adopters and could very easily become early the next group of vocal detractors. I can't help but wonder about the poor client advocate Stripe fired before they made this move.
I created an account and integrated Subscriptions in 2018. At no point was I told that I would later be charged extra for doing so. On the contrary, I was later told that my account was "upgraded" to Billing for free.
> I'm sorry that it feels that way.
It's not just that it feels this way. It is this way. I'm still on the Subscriptions API and haven't seen anything in Billing compelling enough to rewrite my code to implement.
I'm not saying any other payment processor is better. They may not be. It's just that while I deeply respect some of your broader ethical stands, this kind of behavior is dismaying.
You don't need to! The pricing doesn't kick in 'till next year. We want to give people time to migrate away or to implement a billing system manually. (And if anyone wants more time to do that, we're happy to grant it.)
If I reach out to support, will they be able to chat w/ me about what's actually happening? I'm pretty confused atm, and don't want to drown this thread with questions about what's actually taking place.
Patrick, Thanks for building a great product. I'm happy to pay for continued feature + new product development ...
... What I'm not so happy about is:
* we have asked Stripe to sign a contract for years (something requested by our institutional investors but have always been just pointed to an online MSA URL
* we are now being asked to sign a contract suddenly w/new line-item charges and no ramp-up or notice period
Most companies (especially those that are PE backed) have already done year end planning + budgetting.
Happy to provide the details of our timeline but so far at a high-level:
* contacted by a new account rep 11-days ago about signing a contract
* still have not received the proposed rates for billing, processing, rev rec, sigma etc ...
* ... but have been told that Billing charging needs to kick off 1/1/2021 (which is essentially 45-days away)
Thanks pc! OT: You're very active, and usually one of the first to get involved, in Stripe-related discussions on HN. I'm curious how you manage this. Do you lurk HN all day like me and spot the new Stripe-related threads, or do others at Stripe let you know when they see a Stripe-related thread?
I've always wondered if there is a business opportunity here: a company that monitors social media for all mentions of your business and pings you about it. Maybe this already exists?
I do think there are existing applications that provide this service (ex: Hootsuite[0]). I think a layman could probably setup Google Alerts[1] to achieve the desired results for topics they're interested in (like your company)
I'm curious how Patrick does it though as his attention isn't exactly cheap
Media monitoring companies have been around for some time. There are companies with people transcribing talkback radio and reporting to clients (including sentiment, etc) for companies and topics mentioned. Would be easier to automate in the age of social media too, so bound to be dozens of upstarts focusing on that.
Patrick, i am trying to build a partnership with you guys and can't get anyone to contact me back. We are a venture backed startup in the veterinary telemedicine space - how do I get in contact with someone senior to explore an enterprise level partnership?
Edwin from Stripe here. It’s worth distinguishing between charging money on Stripe (for which you incur payments pricing) and using Stripe Billing (which is a separately-paid product).
Stripe Billing has had this pricing for a few years. For some longtime users of Subscriptions, we originally didn’t change their pricing but are doing so now. We think charging a separate fee for our Billing product is fair, given comparable products in the market (say, Recurly or Chargebee) charge something similar. (Generally more!)
We’ve been investing a ton in making Stripe Billing better. For example, from talking to users we learned people needed it be significantly easier to get up and running with subscriptions. So in the last year we built the Customer Portal[0]. (We’ve also listened to you and improved the analytics[1].) Payments is a low-margin business and our customers are (quite reasonably) very price sensitive. So to be able to make Billing a great product, we realized it was going to have to charge a fee commensurate with the product scope.
Thanks for jumping in here so quick. I'm sure it'll be a tough thread, but something about this response rubs me the wrong way. It doesn't seem like it's really addressing the change (eg. why is it worth _existing_ customers to be paying an extra 0.5%? The fact that Stripe added features for new customers doesn't really impact those of us who have been with you for 5-10 years). Additionally, I don't recall getting an email about the price increase.
I genuinely don't even know: am I going to be seeing this price increase? Would have liked getting an email about something like this, rather than finding out on HN, and now having to dig into things to figure out if I'm actually affected (which I presume I am).
To give you a comparison: if my bank or credit card company increased their rate, I'd expect to be (and am) notified of that.
I don't think this is a pricing increase? It's just their pricing for Stripe Billing. It's been 0.5% since at least 2018 which is when I started using it. I'm not sure why this has suddenly exploded on HN.
IIRC, Stripe used to have a "subscriptions" API at no extra cost. A few years ago, when they launched Billing (with the 0.5% fee), they moved everyone over to that but grandfathered in the old pricing. Now they're making everyone pay for it.
They've been chipping away at the grandfathered accounts this year.
What bothered me the most was earlier this year when they stopped refunding fees when issuing refunds. They rolled out a feature during the early days of the pandemic, and in the same week they started charging older accounts for refunds https://news.ycombinator.com/item?id=22371330
> If a refund takes place, you will also be refunded the following transaction fees:
> - The domestic processing fee (for example, the 2.9% fee)
> - The cross-border processing fee (for example, the 3.9% fee)
> Note that the Authorization fee and Disputed chargeback fee are non-refundable.
So it looks like Amazon Payments holds onto the 30 cents but refunds the variable part. It's obviously not zero, but for a $100 domestic charge Amazon's 30 cents is much less than the $29.30 that Stripe pockets.
I think it's because Stripe has for a long time branded themselves as being priced simply. Reading that there is a price increase, I think, warrants a noticeable reaction, since it could mean a new 0.5% cost for every business relying on them.
That can be a lot of money for some people, and in general, I'm a bit disappointed that I found out about the Billing product increase through HN. I would have expected to get an email from Stripe, maybe a month ago, saying "Hey: our rates are going up on 12 November"
Careful. They might want to develop one more dashboard - showing you structure of the fees and their changes. Brace yourself for another 0.5% fee to pay for it
Yes, you'll be emailed—if you were on the old Subscriptions pricing and are using Billing now, the emails are going out now (most have already been sent). Email me at edwin@stripe.com and we can also check.
And to be crystal clear, the emails should be done sending today. The changes—which will take effect on January 15—only apply to businesses that have had at least $1M in lifetime billing volume (or will cross that threshold this year). All others can continue to have Billing for free.
If this million dollar threshold had been made clearer, I imagine a decent chunk of the people who are upset by this change would have reacted differently.
We think charging a separate fee for our Billing product is fair, given comparable products in the market (say, Recurly or Chargebee) charge something similar.
Copying what other people in the market are doing is the antithesis of what made Stripe so important when it first launched.
Processing margins are thin and they have a valuation ($36B) to justify, so they have to grow product margins where they can ("going upmarket"). Market realities/constraints.
That only works if you have a number greater than zero to multiply your margin by, though. Stripe is already relatively expensive among the payment processing options we have available. In the early years, that premium was justified for us because Stripe was also much easier to set up than anyone else at the time. But that was nearly a decade ago. Today, there is far more competition from other payment processors, while the experience of using Stripe as a merchant is far worse. I'm assuming that they've simply decided to focus their business on the larger merchants who are obviously worth much more to them individually, but those merchants surely have negotiated rates below headline and won't be paying an extra 0.5% for this either, so it's a puzzling move.
Well, if you start comparing yourselves to chargebee, they have a far more complex product - and really impressive traction in terms of new features being released regularly - combined with a really super support. I have not even seen a single company that deliver on the same level as chargebee does.
I've had to run a number of price changes (mostly increases) over the years. In case the folks with pitchforks are unclear, your mistake was not clearly communicating to your customers. Every impacted customer should have received an email that explained the change, how much their bill would increase, and a timeline for the increase that would give them a few months of runway make other plans.
How about: they're increasing the price to X because that's what they want to charge. They think price X will help maximize the long-term value of the company.
Sure, they can say that and be honest instead of trying to marinate us with these gymnastics; it's insulting too that they believe we can be manipulated like this.
Yeah I mean, maybe being larger as a financial institution has some costs also. Primarily that it sucks. I interviewed at a hedge fund that had to submit (something) to (some regulatory body, don’t remember) because it was too systemically important. But they required dedicated staff to handle the regulatory burden. Given how tightly staffed that place was it was actually a meaningful portion of headcount measured as a percentage.
Maybe some of those economies of scale are only 80% realized if you’re a financial institution. And rightfully so.
Don’t have a horse in the game here re: Stripe, just hoping the damn kids will go on someone else’s lawn.
AWS doesn't charge anything for elastic beanstalk beyond the standard price for resources, even though of course competing products like heroku charge a lot more. I'm not arguing about fairness, I'm sure that's not a concern for AWS either, but if you have a basic product with solid margins, doesn't it make sense to account something you build on top of that product as marketing or documentation, rather then as a distinct product that has to pay for itself?
Awesome, I setup subscriptions using Stripe for a website a few months ago for the first time and was so turned off by how convoluted the process was I was actually thinking about emailing Stripe to suggest they take a hard look at the process and how to make it easier. Glad to see that was already underway, great work!
At the end of the day, you're using electricity to send around a bunch of 1's and 0's. The amount of electricity used doesn't change much whether it represents $10 or $100,000...so why do you need a percentage of the total?
I understand existing banking structures already work on the percentage model (so there's probably downstream percentage-based charges Stripe must pay), but why can't this entire banking structure be disrupted to transfer that value back to society?
Cost-based pricing rarely makes sense for software products, as almost all products are just “sending around a bunch of 1’s and 0’s”. If that were the case, almost all software would cost just pennies a month.
I’m not a fan of Stripe’s price increase for recurring plans either, and I think they could’ve communicated it better, but their pricing is far from unreasonable given the amount of research and engineering effort they put into the product that I don’t have to do myself.
Correct — Subscriptions was the really old one. Two years ago Billing was rolled out as Stripe's separate product for recurring charges and invoice management (https://stripe.com/billing).
We (Streak yc s11) signed up for Stripe way back in the day and have just been paying their standard payment processing fees for years. We haven't upgraded our API version or used any of their new billing features or anything like that. Basically we get the same value from Stripe we did from the day we integrated. I thought our pricing was going to be grandfathered but this change will cost us tens of thousands of dollars. Unfortunately, we're kind of hostage to it.
Anyone else at scale and have an old integration? How are you handling the fee increase?
If you're doing significant volume, which I assume Streak does, you can negotiate significant volume discounts. You have been leaving a ton of money on the table if you have not done that.
Maybe - they seemed really not interested in negotiating much at all and I got the impression they feel that their customers should be lucky enough to be allowed to use Stripe as a processor.
My company went through negotiations with Stripe earlier this year. We were more than 1.5% + $0.10 away from our current processor, and they wouldn't budge to even match our existing rates. They kept saying they are a better value, and offer more things for the price - except most of the "value-adds" we didn't care about (their only interesting things was the Stripe Checkout with Fraud detection - which requires you to use their hosted checkout page... which is a complete non-starter for a serious eCommerce operation).
Perhaps not a good fit - but paying a ton more per year in CC processing fees just because Stripe uses "AI!!!!" wasn't something we could swallow.
Would you mind sharing which processor you are using? Seriously considering moving away from Stripe after todays news and since we have to implement basic subscription handling ourselves anyways or pay more ransom to stripe.
Would be much appreciated.
We do not make use of any automated billing/subscription features, so what works for us isn't necessarily what will work for you.
I believe they've changed the name now, but we're using what used to be call PayPal Payments Pro, which is just a processor (customers stay on your checkout page, you build the checkout form, no PayPal account necessary for the customer, etc). We were using CyberSource when PayPal approached us for negotiations - they ultimately made an offer we couldn't refuse (based on volume) and made the switch. This CC Processor product from PayPal has none of the baggage or horror stories you hear from people using PayPal Express Checkout - it's almost like you're dealing with a completely different company.
That's not how they pitched it to us - and I asked for clarification multiple times because of how absurd the proposal was for a well established eCommerce site. Sending customers off-domain for a payment is not something we were willing to do for a normal credit card checkout flow.
Even "hosted fields" is absurd (and by that I assume you mean an iFrame you embed), and would require redesigning significant portions of the checkout process.
That, coupled with their refusal to even match our existing rates, was really off-putting. The sales people made little effort to understand our business and pain points - they just wanted to talk about how great Stripe is and all the AI stuff they do.
"hosted fields" are really just a fancy CC # widget (with postal code and exp built-in, when appropriate). If you use them, the annual PCI attestation becomes a checkbox instead of a giant form.
actually hosted fields isn't an iframe but replacing the cc detail fields with stripe fields and adding some javascript which tokenizes the cc details so you never see them
You don't have to use "hosted fields", but it does mean you have significantly increased requirements regarding PCI compliance (SAQ D vs the much simpler SAQ A, for example).
Not necessarily true. It depends how your site is setup.
Users of eCommerce platforms generally will be SAQ-A since they are not the ones controlling the system which handles CHD. This covers platforms like Shopify, BigCommerce, 3dCart, Volusion, etc, where the platform itself must be PCI compliant on their own, separate from whatever PCI level you are compliant with.
If you self-host, such as Magento, XenCart or some custom implementation - then yes you will be SAQ-D.
I guess the point was, that "feature" was the only value-add we cared about, but not enough to pay thousands more per year for effectively the same service - accepting credit card payments.
Your sales team walked away from the negotiations after a while because we weren't willing to pay significantly more just to have the brand "Stripe" be part of our business. It really was a "but, but, we're Stripe! AI! Why don't you just agree to the terms? AI!!! Did we tell you about the AI!?!?!".
I suppose it was Stripe's loss in the end... and I imagine we're not the only company that had this experience.
I have the impression Stripe's "bread and butter" are small-time shops (partnered with Shopify where 99% of sites generate < $1MM annual), hobbyists, and similar smaller operations that either can't negotiate better rates due to low volume, or don't know they can negotiate better rates due to high volume. Nothing is wrong with that - it just means Stripe isn't a good fit for companies with significant volume.
haha we had a similar story with a company (not payment tough) all they said was AI, we are better, so we charge more.
but who cares if you charge 10x more than your competitor, with 10x more you need to be at least 100x better.
We stayed put actually. At the end of the day, you need a processor that charges low fees, provides easy tools to handle chargebacks and refunds, provides tools to automate sweeping balances nightly, and doesn't go down often.
People don't switch processors often, so building out an integration once every 10 years isn't a big deal if you design your integration correctly.
That, and I assure you, your customers don't give a darn about which processor you use.
Could you define "significant volume" a bit more specifically? Wondering if I too, have been leaving a ton of money on the table. What is the approximate scale that this makes sense at?
Same thing has happened for Radar for example. We set up our whole infrastructure with their beta 3DS and Radar products, and then one day (a few months back), it is $ 0.07 per txn in Radar as well as no returned fees on refunds.
Stuck with nowhere to go.
Not against improving margins, but customers that have walked hand in hand with Stripe for so long and seen them thru their early growing pains should definitely be grandfathered.
Because it creates a reputation that choosing Stripe is a safe move for a business. Like how AWS never increases prices. It allows businesses to lock themselves into the platform with little worry which makes the platform owner profit in the long run. Businesses don't want sudden costs one day that they couldn't budget or plan for.
Oh yes! To Grandfather or not to Grandfather! That dilemma!
I understand they are still using the same functionality they had at signup time, and are still on the same API version, so not taking advantage of new direct functionality.
Yes, of course there is a bunch of indirect functionality or magic behind the scenes, but from a company lifetime perspective, when you enter into an agreement with a service provider, you would expect a relatively constant delivery of services, at the agreed prices, especially if your needs have not changed.
There are many companies that upon adding new functionality or services, decide to grandfather. New direct functionality comes at new prices, even if you are inherently benefitting from the new stuff.
Three I can think of, Zendesk, Customer.io and Geckoboard grandfathered our plans.
When it is easy to switch providers, grandfathering is not that important, but if you're tightly integrated, which pretty much everyone doing volume on stripe is, then you're screwed. You can't leave.
Even if you negotiate custom pricing, there is a knock on the door one day saying, "new pricing in place. Take it or leave"
The day you decided to go with Stripe you started being hostage of them, but this is not a bad thing, this is business, you choose a partner, they are allowed to change the terms if the contract permit it.
People on HN always think they deserve to be treated better than others
>People on HN always think they deserve to be treated better than others
I have noticed a significant attitude of, "I originally signed up for this product with 'x' cost and 'x' features, and you have zero right to change anything about that."
It seems like a basic contract negotiation process would ferret that out - I thought that was a business thing to do. I work in higher ed, and we absolutely have to have contracts for all third-party vendors; any changes are negotiated with the start of new contracts. If we can figure it out, surely startups can - we're not really all that good at efficiency.
I think trust in your providers treating you well is required for low-touch SaaS sales for key infrastructure to work well. If you don't trust your counterparties, then you get long contract negotiations and minimum viable contract sizes balloon, as many potential buyers just won't be willing to be dependent on your company without assurances.
Exactly. Certain SAAS companies (cough Datadog cough) seem to have very old school sales processes in place. I don't love the larger cloud providers, but at least they lay out their standard prices, supply a price calculator, and I can figure out if I want to use them without hearing someone tell me they'll have to "clear it with their director".
I imagine anytime someone says the have to "clear it with their director", you're talking about discounted or private pricing not the list pricing they have on their website. Every SaaS company has that, including the cloud providers.
Well yes, one wouldn't be talking to them in the first place if it were on the website. For many companies though "Enterprise" plans are always non-website prices, so there's nothing special about negotiating them, and the salespeople pretty much always are just saying that stuff to have a chance to go away, recalculate their monthly commission chances and figure out the price to try with you rather than actually seeking permission.
That's why we integrated with 4 payment providers. We use a common Quote object that knows how to "apply" itself to subscriptions on all 3 (GitHub is inverse) providers.
I have to believe this is Stripe leadership pumping up the revenues/profits to look peachy for their IPO, so they can all get a considerable exit while raising a war chest - meanwhile competitors will come along and try to take market share while Stripe can spend more on acquisitions and feature development for the same price. I think this play as part of the VC industrial complex leaves them more vulnerable than is obvious - but leadership won't ultimately care because they're set for generations.
If the Stripe leadership wanted to exit and be set for generations they could’ve done it years ago. I agree it could be a revenue boost to prepare for IPO but this isn’t some personal greed thing
Personal greed doesn't magically end just because you want $5 billion instead of $1 billion. Greed is greed even if the only point of it is having a larger number in your bank account or higher social standing from it.
Without knowing their business model, it really doesn't matter how much money is moving through their system. It could very well be that they have a lot of buyers because of a very low profit margin and this actually has a notable impact on the company's finances.
Saying you are "held hostage" might be a bit of a dramatic way to phrase it, but for some companies a change like this actually makes a difference. Such is the life of relying on any third-party services though.
Also, pointing out "faults" is not helpful. It's unproductive conversation. Many companies are built upon third-party services that they are (probably falsely) under the impression will not change. It's not your "fault" if you decide to use AWS services and become deeply integrated and they increase their prices by 10% and you can no longer afford their services... It's no one's fault. It's just unfortunate and all you can do is try to work around it, or close the company.
> It could very well be that they have a lot of buyers because of a very low profit margin and this actually has a notable impact on the company's finances.
This is the real problem.
From the sidelines, it's easy to dismiss an additional 0.5% overhead as trivial. After all, that's less than 1%, right?
But it's not so simple. That 0.5% comes out of the profit margin. If a company has 50% profit margins, losing that extra 0.5% isn't a big deal. However, if a company is operating on 10% margins, that 0.5% suddenly becomes an extra 5% overhead.
> It's not your "fault" if you decide to use AWS services and become deeply integrated and they increase their prices by 10% and you can no longer afford their services... It's no one's fault. It's just unfortunate and all you can do is try to work around it, or close the company.
It's your fault if you chose lockin. If you don't want to talk about fault, fine, but then don't go on to talk about fault :)
Most people don't choose lock-in. They choose a provider that works for them on the budget and timeline that they have, and they build on that. Expanding to multiple providers isn't always feasible depending on a company's business model and financial state - it takes time and development resources to do so, which can both be very sparse for company with tight profit margins.
You have to start somewhere. Unless you have been handed a substantial amount of starting money and baked "we need to be provider agnostic" into your company beliefs from the beginning, it's rarely an early priority. Becoming profitable is usually what comes first. Securing a stronger foundation for your platform comes over time.
> If you don't want to talk about fault, fine, but then don't go on to talk about fault :)
Yeah, I know. What I'm saying is taking the seemingly low-hanging fruit of locked in technologies is a conscious decision to be competitive. It has very obvious pros and cons. The cons potentially materialising is part of the choice.
> What is the point of saying this?
Whatever criteria you used to justify asking this question probably also apply to it.
I think OP's point was, if you're moving that much money, you shouldn't be relying on a third party vendor; doing so shifts the blame from them, to you, for not controlling your own payments. That's what I read in that post.
There’s a big difference between “millions of dollars” and “relying on a third party vendor for payments.” I don’t know of many sub-$1B companies that implement their own payments infrastructure...
> You're not a hostage. You're deeply integrated through nobody's fault but your own.
Exactly this. We started being Stripe customers after they bought some third party several years ago. While Stripe maintained the deal it was good for our business but recently they decided to end the deal we had (I don't blame them, it was a very sweet deal for us). Fortunately my startup always have had more than one provider and now we can calculate a "least cost routing" process, which will definitely move a lot of our volume outside of Stripe.
But it is just that, business. You should not trust any one provider with your business, not even AWS (i.e. not even at that level).
Move to another solution? I have no idea on pricing but maybe NMI, Braintree, etc. Also play hardball with the account manager if you're comfortable with that.
Why are you hostage to it? How much dev time would switching to a different transaction processor take? This seems like it should be a very competitive space.
It’s not just dev time, that would be easy. It’s getting every customer to re-enter their credit card details which won’t happen without a significant uptick in arrears, and depending on the type of customer, churn.
> Data portability is a solved problem in this space - so there isn't a material risk of churn due to a migration like this.
Here's my anecdote of a different situation but with some similarities, where we couldn't get the data portability we wanted.
A few years ago I asked our Direct Debit provider if we could migrate customer subscriptions from our old business entity to our newly incorporated company version of the exact same business.
The old business entity was to be wound up as a complete transfer to the new one, the trading name was identical (transferred along with trademarks), and we were happy to keep the same DD provider.
The answer we got was no, each customer would have to enter their bank details and agree to the same terms again. From the customer's point of view, they probably wouldn't even notice it was a different business, because in a real sense it wasn't.
We decided this would lead to significant churn in customer subscriptions, and we couldn't afford it. It would be cheaper to maintain and administer the old business entity, for no business purpose whatsoever, just the sole purpose of continuing to receive the DD subscriptions, and pay them immediately in full to the new business entity.
We wanted to move ~300 credit card details from SagePay to Stripe. SagePay had a minimum admin fee of 2000GBP in order to do this, and no amount of negotiation could shift it.
If anyone's had a better deal from SagePay - let me know.
This is fantastic thank you; I thought our customer card data was effectively held hostage in Stripe so the only way to move customers to a new system was to wait until their credit cards expired and were updated.
We're planning to migrate away from Stripe after this latest in a line of price increases.
Indeed, there needs to be laws for data portability to allow a true free market mechanism so then if a company isn't providing reasonable value for their fees, people will be mobile and can shift away without friction; Facebook has survived because lack of adequate data and network portability.
Wouldn't help with credit cards. Plus I'd guess the idea is that you want to have some friction between you and the thousand companies that you have a transaction with in a year.
We recently finished moving our "Recurring Billing" stack from Stripe to Recurly after we found a tonne of problems with the Stripe billing setup. We still use Stripe as a Payment Gateway but we migrated off of their "Billing" product.
I think a lot of those problems related to us being a European business and Stripe not quite being there yet in regards to Tax and Invoicing but now we have switched it's really shocking to me how steep of a price Stripe is placing on a somewhat lacking billing system here. I always assumed their Billing product was there to lock people in to the payment gateway and make it harder to have Interchange++ pricing negotiations.
What's particularly sad is that I have fond memories of the early days of Stripe when I was genuinely excited to use their recurring charge product because the developer experience was so nice.
Today with VAT MOSS, SCA and a larger team the Billing product is neither easy nor powerful for us.
One saving grace for anyone else who finds themselves with an expensive / insufficient Stripe integration is that they make migration out very easy. We were able to get the whole process done with no downtime or missed billing - so it's definitely possible even when dealing with complex billing arrangements.
Stay tuned on the European tax stuff—we're working on that now. (And if you want to talk more about it, feel free to email kmoriarty@stripe.com and me at edwin@stripe.com.)
This is funny timing for us - we are currently looking at implementing a subscription service and were already looking at this price. Even so, 0.5% fee is miles away the cheapest option. (Most others want a fixed fee per month plus .8%).
Is there reason for us to be scoffing at the new price? This is still a fraction even of processing the credit card.
Is there any downside (other than a little more work for the implementer) to just using their main payment processing API, and to implement subscription billing with a cronjob? This is what sr.ht does [1], at least as of a year ago. If doing it manually now means saving a bunch of money, seems like a no-brainer.
We did that for a couple of SAAS. In fact, we even extracted this out to an internal library with a web UI. If anyone is interested, let me know and I’d be happy to open source it. It’ll have to be run in its own server and process.
But for full disclosure, my latest project just bit the bullet and accepted the extra 0.5%. Wanted to see how it goes. Could always switch if I found the need.
The downside is that you have to write and maintain the code and infrastructure to do it. You have to do the math for your business to decide if those costs are lower than the 0.5% fee.
Stripe still doesn’t support settling USD payments into a USD bank account on an Australian Stripe account, instead forcing their 2% currency conversion fee on top.
So my fee for every subscription charge is increasing to a an even more ridiculous A0.30 + 5.4%.
Our users have been asking for PayPal for years, and I had always put off integrating because of how frustrating their API was. But it feels like the Stripe developer dream is over. Fine, I’m adding PayPal support. :(
Recurring billing is hard stuff. If you haven't touched it and don't know what Dunning means, or how to handle upcoming card expirations, or proation, or mixing one-time and recurring purchases, then you probably won't appreciate what kind of value is provided by a 3rd party service. Its a wonderful thing to outsource for many SaaS companies. If you have a totally novel business model with unique billing requirements it may make sense to build, otherwise its almost universally cheaper and more maintainable to buy.
For example checking upcoming card expirations is running a DB query on a daily background / cron job that returns cards where the expiration date <= some threshold that makes sense for your app (maybe 2 months). It's like 3 lines of code with most popular web frameworks. Typically you'd be storing a card's last4, card type, exp date and an association to a user in your system so this info is handy.
It doesn't take much more effort to send emails out as warnings for that. I've done it in a few systems before Stripe had this email feature.
The smart retries is interesting but this feels like another thing where Stripe is happy to collect our data but then re-sell it to us at a premium once they've gathered enough data. Similar to having to pay a lot more money per transaction to get fraud protection rules (Radar). Basically we pay Stripe to train their system and then they double dip and charge us extra to use these features.
> We doing DB/cron queries now with "web frameworks" ? :O
It depends on what web framework you use, but yes.
If you had a Flask, Django, Rails, Phoenix or Laravel app it's a matter of writing a DB query in your ORM / data mapper of choice and having that execute on a scheduled job using Celery, Sidekiq or Oban (a couple of different popular job processing tools).
So yes in those cases I would treat that as something my web app handles. Going into the implementation details of ORMs and background job processing strategies didn't seem important for the sake of that post. The takeaway is it's possible to solve that problem with very little code in a typical web app.
Recurring billing is not trivial, but it's not performing open heart surgery either.
The big time waster these days, at least for those of us around Europe, is the tax and regulatory hassles. But Stripe and other payment services following similar models offer limited help with a lot of that stuff anyway.
Confused because I thought Stripe Billing referred to the Customer Portal functionality and some advanced Stripe Checkout features like customer-facing promotional codes. I thought subscriptions were part of the core Stripe functionality. Can anyone clarify?
It’s what I thought as well. If we knew it’s gonna to cost us an extra .5% of revenue, we would have built our own billing system instead of hacking one around Stripe one.
I'm pretty disappointed by that move from Stripe as well to be honest. When we signed up long time ago we were not aware that the basic functionality of subscriptions was offered for free only temporarily.
We use the stripe backend only to create and cancel subscriptions, that's it. Now we have to pay a couple of grand a year to do this or hire a developer.
I think a much better move would have been to add a new billing plan for the few new features that have been added, but leave people with the basic functionality that they grew used to.
And c'mon, narrow margins my ass. We are not talking about a small startup here, we are talking about Stripe, a billion dollar company! They should be able to afford having a developer or two working on those long neglected features and not compare themselves with chargebee. It's just sad.
The idea that the ongoing cost of moving money between parties varies on the amount of money moving is very "sus" as they say. Whether they move $10,000 in a transaction or $3, roughly the same number of bits move, the same number of algorithms kick off, and so on.
Is there a cost-based rationale for doing a percentage-based pricing model, or is it really "because they can"?
I could brainstorm and say "fraud" or "defense against lawsuits involving large transactions" but those both feel weak.
Much of the interchange rate is charged directly by Visa / Mastercard. The merchant bank will then add basis points to that, and often you get another mark-up by the individual ISO (independent sales organization) in a typical set up. So, then, why do card processors charge percentage? Well, when you see those Capital One commercials where you get 1% cashback on this type of purchase or 2% cashback on this, that's where the money is coming from.
Companies like Stripe shield you from the intricacies of interchange pricing but if you operate on interchange + (meaning, the merchant account provider is charging you interchange + X %), you see that processing corporate rewards cards are the biggest killers, because you are essentially covering their 2% cashback programs. Additionally, some of that cost is insurance. If you have a fraudulent charge on your card processors work with your banks to cover some of that money, which they make from the overall % of total volume.
Not saying any of that is right, or an ideal situation, that's just the why.
Just to note, interchange in the EU is capped at 0.2-0.3%. Stripe charge 1.4% + €0.25, so that's not the full story (there are scheme fees too, but I assume Stripe is still making some margin on the % fee - but open to correction on that)
Absolutely. I took the question as to why a percentage is charged for card transactions at all. The additional 0.5% is most definitely a "because they can" type of pricing and that's more an economics theory discussion. The market has shown a willingness to put up with that pricing and therefore a value proposition is set so until something changes no reason to price differently if the market is willing to pay a model with a much higher margin. I don't necessarily agree but that's a sound short-term business decision. I know from experience that sometimes going into a market with an established pricing model, however unfair, with a better pricing model for the customer can be bad for business and result not only in less profit per sale, but fewer customers making the buy decision because of the pricing model expectations that have already been set by the market. It baffles me, but I'm no economics major.
This thought is exactly what the company I work for is thinking: https://www.paystand.com/about (B2B SaaS payments, fixed monthly fee)
The majority of the current payment cost (2%+) happens when paying by card. But as you say a payment right now is just moving bits. The main reason why cards charge so much is due to Risk. If you read about "interchange fees" you will see how Visa, Mastercard, AmEx, etc. classify different cards into different levels and charge a different exchange rate for each of them.
But the thing is, this system and networks were created last century (around 1960) and nowadays there is better technology to assess risk and to perform the transactions.
Percentage of revenue based pricing is very common in enterprise software and not without reason.
How angry is a customer over a $10 payment not going through vs a $10,000 payment not being processed correctly? We're likely talking the difference between the inconvenience of not having Netflix for a few minutes vs you've just cost me $35,000 in lost sales because my subscription failed and you can't find out why on time.
I want the company who made $50 on that transaction helping me, not the company who charged $1.40 flat rate and needs to budget their offering by limiting development and support.
The simplest way to fairly charge everyone an appropriate amount for the risk that Stripe takes on by processing their transactions is as a percentage of the transaction.
I guess this is a good example of why we should be building a very flexible abstraction layer between our payment services and the payment processor we use.
We don't need to be held hostage - but probably will if we're not careful.
> As an early user of Stripe, you have had free access to Stripe’s machine learning based fraud protection tools, Stripe Radar and Radar for Fraud Teams.
We're very happy ChargeBee customers - I guess this doesn't affect us as we only use Stripe to store the card details - ChargeBee is the actual recurring billing engine.
I just had a look at the pricing, and I'm a bit confused. Take the base plan for example, £199/month - it doesn't mention any other charges, and is apparently all-inclusive; or do you have to pay card processing fees on top?
As a Stripe user, it has never been smart to use recurring charges, or most of Stripe's other advanced, hands-off features. It's much, much better to just store payment source IDs and run charges in a cronjob. This gives you the flexibility to leave Stripe more easily when they make changes you don't like. Keep your integrations lean, dependencies are a liability.
We really need a way to facilitate money transfer between one or more parties. There are way too many middlemen (credit card processor, credit card network, bank fees, merchant fees, exchange network fees, ...) that artificially inflate the cost of products and services.
This is likely worsened when you consider transactions between parties in different countries.
That was the intention of things like https://nano.org/. If merchants started offering products 3-5% off for paying with crypto, they would probably come out ahead.
I hope they can also innovate more on behalf of the customer with regards to recurring charges.
PayPal has this management console where a customer can see all recurring charges and instantly cancel any of them with one click: https://imgur.com/a/lLE3iAt
IMO, this should be standard across all payment cards. I detest businesses that make it hard to cancel recurring charges and I think payment card providers need to stop that from happening (I get Stripe is not quite a consumer card provider...yet).
There's a fixed cost to put a transaction onto the card brand networks. Recurring includes dunning management which retries failed auths. If you rolled your own, you'd be paying for the declines.
Stripe is charging extra 0.5% for the billing feature, so a billing charge goes in the US with stripe 3.4% + 30¢. It could be done for 2.9% + 30¢ + 5¢, stripe will still get the its cut, but not the extra 0.5%.
¢5/transactions for billing services we could do it, might need some small seed funding to set up a small dev team. Do you think we could get interest customers?
You could get customers, but you'll quickly learn they ask for very complex features, and you'll struggle to pay your dev team with 5 cents per transaction.
Complex customers can use 0.5% extra service from Stripe, they could even build their own solution. Billing, recurring, invoicing can be done here. What could be interesting is setting up a billing service that the client brings its own Payment Service (checkout.com, stripe.com, adyen.com).
Thank you, I feel exactly the same. I assume at this point any use of subscriptions in Stripe means we are using Stripe Billing, but the messaging is very unclear.
I've changed the title from "Stripe is now charging 0.5% more for recurring charges", which apparently is misleading, to one that is, though clunky, apparently accurate.
If anyone can suggest a better title—that is, accurate and neutral, and preferably with less clunk—we can change it again.
> "Stripe is now charging 0.5% more for recurring charges", which apparently is misleading...
Stripe is indeed stating they'll start charging me 0.5% more for a service they said would be free for me when I signed up. They've done this by renaming the service from subscriptions to billing and adding features to it that I've never used. According to others in this thread, the message they sent out two years ago was:
> "Your account has been upgraded to Stripe Billing for free. No matter how much revenue you process on Stripe, you’ll get unlimited use of Billing’s Starter plan included in the price you currently pay for payments. All new features are available in your account now, no API version upgrade necessary."
This is what I remember as well.
I'd say a good title would be, "YC-funded Stripe moves Subscription customers to Billing, increases their fees and breaks earlier promises". The original title isn't as nuanced but is still more accurate than the current one, IMO.
I know nothing about the intricacies of Stripe product offerings, so need to rely on others to come up with an accurate title, which is (as always) our intention.
The submitted title implied that Stripe is raising its prices on all recurring charges. As I understand it, that's not true; therefore that title was misleading and needed to be changed. (Site guideline on this: "Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html)
If there's another title that is even less misleading, we can change it again. Btw, as a rule, the best way to complain about a bad title is to propose a better one. We can't come up with all of them and often adopt community suggestions (a few examples: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).
That contradicts what's said elsewhere in the thread. My understanding is that prices are going up for the earlier users of an older product who are now being moved to a newer product. It's understandable why they and others wouldn't be happy about that, but it's a different situation from what you're describing here. If that's wrong, I'm happy to be corrected. Like I said, I have no firsthand knowledge, so have to rely on people who do.
This is particularly annoying since Stripe Billing was initially free, you start using it and now it suddenly costs 0.5% * revenue. Which can be quite substantial. The more frustrating part is that it's currently at best a beta quality product. Reporting and interface for the finance side of the company leaves a lot to be desired. Anyone know any solid alternatives?
If you are looking to manage subscriptions outside of Stripe, but keep using Stripe for payment processing, take a look at Kill Bill, the open-source subscription billing & payments platform: https://killbill.io/
The expectation that Subscriptions/Billing would be free forever is silly. The product offering is significantly more complex than the base Stripe offering. Additionally, the proposed rate of 0.5% is 1/10th what other repeatable billing providers are charging.
This is a win-win and I'll be moving my startup over to Stripe Billing in the near future.
Nobody is a fan of extra charges, but I am quite happy with Stripe since it's simple enough to use, by now powerful enough to be used even with bigger customers and for us it was the biggest road to being able to send out invoices to customers abroad which can be paid via Credit Card quickly.
Look at it this way: If you're serving big customers on annual plans you can always include text on your invoice about how they can pay via SWIFT / SEPA wire transfer. Of course you're still eating the currency conversion and bank handling fees for accepting those payments.
For us the pain of the 2.9% + 0.5% percent is not big enough to warrant even researching cheaper alternatives. If someone has hot tips for something that allows me to charge via Credit Card, accept payments in various currencies, and has an invoicing and subscription product built in I'm all ears!
If it adds more value than the cost when compared to other alternatives, why shouldn't they charge something for it? It's not like stripe has anything close to a monopoly in the payments space.
Yeah but isn't that just the way of the world? Processes can become simpler but at a certain point the complexity of the process is inherent and it would benefit you to employ an expert (individual or entity). You can build a house yourself, with your own hands, but why? I'm not an expert on the whole domain of payment processing but it seems to me there is a lot of non trivial problems inherent with taking payments. I guess if you are hedging on a different system of holding and transferring money there may be a way to get rid of the middleman. What do you propose?
I propose the governments require the infrastructure for zero-cost, instant transfers be made available to anyone, with open APIs. I don't care who runs the infrastructure.
If you want subscriptions/recurring payments, stored payment methods and all the "fancy" stuff contemporary payment processors offer, you pay for it. If you just want to move money from A to B, it should be easy and it should be free.
The only way for that to happen is for it to be socially provided service.
> I propose the governments require the infrastructure for zero-cost, instant transfers be made available to anyone, with open APIs. I don't care who runs the infrastructure.
Will this infrastructure handle chargebacks? Fraud? Stolen credit cards? Forex?
If yes, it can't be zero-cost.
If no, it won't be usable until the middle-men build all of these systems on top of it.
Check out the EU (and UK). Open the app on your phone. Tap in a bank ID (routing number) and an account number and an amount. In less than 1 second, the money is transferred to the specified account.
Neither you (the sender) nor the recipient pay anything for this service.
You may have noticed that banks/financial services companies make bucketloads of cash. Why should the cost of running the system always be pushed back to consumers? The EU/UK example points to a different direction entirely.
That may be true, but it's the problem that a lot of us actually have. First and foremost, I want to get money from my customer to me, reliably and in full compliance with any applicable laws and regulations.
On that score, using a direct payment scheme, such as Direct Debit here in the UK, beats charging cards using a service like Stripe on every important point. Lower fees. Much lower involuntary churn due to charge failures. Outside the scope of SCA and all the complexity that introduces. Even for international payments using similar direct payment schemes in other places that have them, if we compare GoCardless for those with Stripe for charging cards, the currency conversion is much cheaper via GoCardless as well because they now work with Transferwise.
It's 2020. Unreliable, overcomplicated, fundamentally insecure, expensive methods to collect some money from a customer and give it to a merchant should have gone extinct a long time ago.
What I described is the core service at the heart of all payment processors. If this service is provided to customers (and merchants) at no cost, then the entire structure of payment processing changes dramatically.
There's also no obvious reason why Stripe and all other payment processors and credit card issuers and banks and financial services should not be carrying the cost of all the things you've mentioned, rather than them being part of the costs passed on to customers and merchants.
If you use stripe to send monthly invoices to your customers (even if they don’t pay by card) this fees is going to apply. If I’m wrong someone please correct me. I’m pulling my hair over this change as a 5+ years old customer.
Post author here. Original title was "Stripe is now charging 0.5% more for recurring charges". Which I agree is a bit clickbait. But the current title is definitely a well-made boring PR title.
2.9% + 30c for a card payment sure, but it's less clear whether making an invoice through their dashboard counts as "Invoicing" as described under stripe Billing. It looks like it does.
That's a bitter pill to swallow when all you're doing is creating the odd (large) manual invoice and have zero need for all that other jazz.
Time to go shave another yak and write a tiny stupid abstraction for this. Useless economic activity for the gdp win!!
For those of you that have negotiated better rates with Stripe or other vendors - are they committed to those rates for some amount of time or total volume?
Stripe billing competes with Recurly and Chargebee. Anyone using those products that has had similar price increases? How were they handled?
I was in the process of writing an email to the mods requesting that they change it to be more accurate when I found they'd already changed it. Apparently I'm not the only user to do so, since someone beat me to it. I have no associations with YC, HN, or Stripe.
Literally anyone can quickly get a HN story title changed if they let us know how an existing title is inaccurate. This is bog-standard moderation which we do all day every day, and it is certainly not limited to YC cos.
The intention is to have a front page with accurate and neutral titles. Call that censorship if you want to (as far as I can tell, that word is just a pejorative for editing that someone doesn't like) but it seems a bit weird to speak of "censoring" titles for being misleading.
As I said elsewhere in the thread (https://news.ycombinator.com/item?id=25074261), if anyone can suggest a better title (i.e. more accurate and neutral) we'd be happy to change it again.
Seems like there should be a mention of a price increase. The current title gives no indication that pricing would change for anyone who isn't choosing to go out and purchase this Stripe Billing product.
This thread is newsworthy for a lot of folks because they are learning that a feature that they thought they were paying for through the standard fees is now only available if they pay extra for a bundle of other stuff (which they never signed up for).
So not mentioning the effective price increase in the title comes across like the someone is hiding the ball, especially because of the YC connection.
How much more can stripe wring out of merchants while signalling virtue?
e.g. 2.6%+ per transaction? Jesus christ.
I worked for a payment processing co. It was all about financial institution connections (uncompetitive). And the costs my company incurred to process payments were negligible.
Yikes! This thread. First time I’ve seen negative comments on Stripe like this on HN. I guess this is what happens when you grow! You eventually become one of ‘them’, start squeezing for the same reasons the folks in the last cycle did, and the cycle repeats.
In my opinion, no one should be using recurring billing for any provider. If you do, you've basically tied yourselves to them--if you ever decide to move, you need to somehow get the subscription details for every customer migrated into your app!
Instead, view your payment processor as just another PaymentProcessor enum. Own the recurring subscriptions yourself, or be willing to pay for someone to do it for you.
That is easier said than done. Managing recurring billing is a significant engineering problem, and getting tied in with a provider and paying a surcharge is still worth it over maintaining an entire in-house dev team to do it.
> Managing recurring billing is a significant engineering problem
This is a huge understatement! Its very painful. It sounds easy, but there are so many end cases with the calendar alone! Let along discounts, prorating, cancelations, etc.
It sucks to become dependent on providers for this service, but it also sucks to have crappy recurring billing.
> Managing recurring billing is a significant engineering problem
It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer.
Sometimes I feel that people have become so used to have a third party API for everything so that they are scared of doing actual engineering work... ;)
That said, of course weighing the cost of dev and maintenance in-house versus paying a surcharge is a very valid consideration. At the same time one should not underestimate the risk/cost of getting tied to a provider for anything critical (and payments are obviously critical).
> It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer.
If you reduce it to "Charge them again after X period" then sure. If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems".
Edit: And dunning. And pro-rata'd subscription changes. And pro-rata'd refunds.
We pay Paddle 5% of every subscription transaction for a reason.
I'm not reducing, this is what recurring billing is. The relevant issues include cancellations, pro-rata refunds, card expiry, calendar calculations (always fun), etc. These are not rocket science.
Handling of tax has to happen on any payment and is not an issue specific to recurring billing/payments. It obviously brings in its own set of issues, the biggest of which is the multiplication of requirements if you want to comply with the rules of many countries, as you point out.
If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems".
It's also not something that a service like Stripe will handle for you to a useful degree.
Edit: And dunning.
Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development.
And pro-rata'd subscription changes. And pro-rata'd refunds.
You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates.
We pay Paddle 5% of every subscription transaction for a reason.
But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.
> If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems".It's also not something that a service like Stripe will handle for you to a useful degree.
And yet it is a key part of the engineering problem that has to be solved, which moves it away from "not one of the complicated problems" and being "quite standard work" (the original post I was replying to, disagreeing with the thrust of their post).
Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development.
We've discussed testing payments before (GoCardless last time) and are in agreement that it can be improved. I've seen no way to test Stripe's dunning.
You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates.
And yet last month I worked with a SaaS which implemented recurring billing a few years ago, and can't get it right. They overlooked pro-rata entirely (which at least prevented edge cases) and dunning didn't work. They aren't the first either.
Which is why, when I see the mess people have made of it, I disagree with the original assertion.
But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.
It is an accurate comparison when answering "[Managing recurring billing] is not one of the complicated problems". We have merchant of records, we have profitable subscription companies like Recurly, Chargify and Chargebee. If it (and keeping up with a changing landscape) wasn't a significant problem for businesses then more would roll their own rather than outsource (and of those that have, get it right).
Reading your other comments on this page, we agree on many more things than we disagree. Here we likely disagree on semantics: what's an engineer's role; what's simple vs complicated? Great to correspond again.
Possibly we're just talking slightly at cross-purposes here, yes. I was intending to comment on the idea that the additional features that a service like Stripe offers for recurring billing management were difficult to implement directly -- the scheduled charges, pro-rating of changes, retries on failure, etc. In other words, the extra features that Stripe is apparently now going to be charging everyone for.
I don't think this stuff is particularly difficult to get right, having essentially done it myself in the past. Indeed, I've never actually worked anywhere that directly integrated with a single payment service without at least some degree of isolation/abstraction. (This is also why features like Stripe's recent customer portal are of little interest to us. Directing a customer there to update their details means they can only change them to something else we use Stripe for, but we don't want to be locked into Stripe like that, we want to offer each customer the full range of payment options we support wherever they are.)
The harder things to implement these days, at least in our experience at my own businesses, are the mechanical integration with all the different payment schemes, where you really do need a specialist service that provides the required access, and the tax and compliance issues, where the ever-changing landscape makes outsourcing this aspect of the setup more and more attractive. But you can get the first of those with many different services and you need something like a merchant of record or one of the dedicated tax management services for the second.
Presumably for some types of business fraud prevention is also a big deal, but again you'd get the basic checks with many services that let you charge a card or the like, and I'm sceptical about how much these fancy AI-based big-data-crunching models are really improving performance. In any case, for those of us in more niche markets, there is little scope for someone to defraud us significantly anyway and the risk of anything bad happening has been very low over the years.
So in the end, with the way the industry seems to be moving, I can see an argument for just outsourcing basic payment processing and then handling the automation and tax/regulatory stuff in-house (for example, if you already have a dev team to implement what you need and you're already set up in some other way on the tax/regulatory side). I can also see an argument for outsourcing just about everything to a merchant of record service. But I think the case for the middle ground model that most of the payment services we've been using over the past decade or so operate is getting weaker all the time. And since they all keep forcing us to do major integration work just to keep the same functionality we already had from breaking and putting up their prices, I can't honestly say we've been feeling a lot of loyalty to any of them lately, hence our ongoing investigations of possible alternatives that I mentioned in other comments.
In my experience, it should be no more difficult than sending recurring emails. You should have all the data (PaymentProcessorCustomerID, LastBillingDate, etc), run it like you would a email with a retry queue.
In the example you gave, how would stripe billing solve that? This seems like you'd need some kind of manual interaction regardless?
For all the end cases, you manually handle them until they happen with enough frequency to require automation. A simple recurring billing system is absolutely fine for most businesses, and as you scale you can add more bells and whistles to it.
I think you're right in this case. I haven't looked at the problem in about 10-15 years (before Stripe had recurring). I remember there being a ton of end cases I had to deal with. We ended up going with Recurly due to it.
I think this is good advice or at least seriously worth considering it.
I remember DHH from Basecamp mentioning this once a few years ago. I forgot if I asked him on Twitter or if someone else did, but it came down to asking why Basecamp doesn't use Stripe's subscription API.
He said it didn't exist at the time but he also said it wasn't a ton of work to get it all working using the basic single charge API. Details are spotty since it was a random tweet from a while ago but the overall feeling of it was it's very doable.
I feel like the topic came up in one of those YouTube videos where DHH walked through real life code in Basecamp.
Even today it might be worth it. I mean if you try to integrate an abstraction on top let's say Stripe and Braintree, there's quite a lot of differences between the 2 for subscriptions. How much more work would it be to write your own subscription logic once and use it anywhere vs writing a really good abstraction.
There's a few startups in this space: see Spreedly, Optile etc. In my experience large enterprises are heading in this direction and managing that abstraction is not something which they want to do themselves (particularly with evolving local regulation/APMs/3DS2.x in Europe).
Hi folks -- as Edwin points out elsewhere in the thread, the article title isn't accurate. (I'll update or delete my comment if it's fixed.)
[Update: it was changed. It used to read "Stripe is now charging 0.5% more for recurring charges."]
You can happily make recurring charges yourself and no additional fees are incurred. Lots of Stripe customers do this and we don't charge anything extra for it.
If you decide to use Stripe Billing, which is a separate product, we charge for that. Stripe Billing's pricing hasn't changed in a few years. What's changing is that we're ending the several-year grace period where we didn't charge anything for Stripe Billing for businesses who started to use this functionality before 2018.
Charging for Billing helps us fund a lot more investment in it -- we've gone from very basic cron-like functionality to a pretty full-featured subscriptions management tool. (You can read more at https://stripe.com/billing.) Billing is now sophisticated enough that companies like Slack and Atlassian are using and paying for it. We've built things like "Smart Dunning" (which improves revenue recovery for failed charges by about 14%), better analytics, international payment method and invoicing support, and a whole host of other features. There are now more than 30 people working on improving Billing.
Importantly, Stripe Billing is (and will remain) significantly cheaper than most of the other competitors in the space.