Live data from Hacker News

Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

stripe.com

211–220 of 331 posts

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#211
post #206

Earlier quoted context omitted.

> 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 weighin…

> 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 subscriptio…

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#212

This is for their product called "Stripe Billing". I have no idea if my subscriptions are on Stripe Billing. So confusing.

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#213
post #101
post #23

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. [1] https://cmpwn.com/@sir/103074952842876982

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.

We'd definitely be interested since we are currently evaluating our options

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#214

Earlier quoted context omitted.

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…

We use recurly.com for subscription management and have been very pleased with them for years.

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#215
post #172

Earlier quoted context omitted.

> 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 af…

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…

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#216
post #172

Earlier quoted context omitted.

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…

> 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 af…

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#217

5¢ made sense, 0.5% is a parasitic approach, the tech stack and engineering costs them 0.1¢ per recurring transaction.

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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#218
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.

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#219
post #190

Earlier quoted context omitted.

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…

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…

I'm in the same boat, is this offer open to anyone?

Re: Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

#220
post #40

Earlier quoted context omitted.

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 val…

How much volume are you doing? That's been the biggest lever I've seen when it comes to Stripe reducing rates
Post reply on HN