Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

stripe.com

Post reply on HN
Print view View original

301–310 of 331 posts

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

#301

Post by porker »

Silhouette wrote: post #244
porker wrote: post #206

Earlier quoted context omitted.

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

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…

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

https://news.ycombinator.com/item?id=25078516

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

#302

Post by robertlagrant »

jb775 wrote: post #245
edwinwee wrote: post #29

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

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…

The majority of most business' costs do not primarily scale with electricity usage.

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

#303

Post by robertlagrant »

Alupis wrote: post #147
edwinwee wrote: post #137

Earlier quoted context omitted.

You don't have to use Checkout for Stripe's fraud detection, which supports several types of integrations: https://stripe.com/docs/radar/checklist .

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

This often happens when companies make a good product and then let salespeople entirely take over the customer facing culture.

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

#304

Post by robertlagrant »

ericd wrote: post #276
Loughla wrote: post #92

Earlier quoted context omitted.

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

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".

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

#305

Post by robertlagrant »

kempbellt wrote: post #80
sigwinch28 wrote: post #46

Earlier quoted context omitted.

An extra 0.5% is going to cost you "tens of thousands of dollars"? You're literally moving millions of dollars a year through your billing platform. That's not a little bit of money. That's a lot. Own it. You're not a hostage. You're deeply integrated through nobody's fault but your own.

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…

> 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 :)

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

#306

Post by joneshones »

Does this apply to creating a manual invoice?

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!!

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

#307

Post by pamonrails »

tschellenbach wrote: post #87

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/

- Stripe tutorial: https://docs.killbill.io/latest/stripe_plugin.html

(I'm a Kill Bill cofounder)

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

#308

Post by spacemanmatt »

merlinbeard wrote: post #173
pc wrote: post #155

Earlier quoted context omitted.

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.)

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.

Strongly agreed.

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.

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

#309

Post by spacemanmatt »

jdreaver wrote: post #109
radihuq wrote: post #103

Earlier quoted context omitted.

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?

Google Alerts?

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

#310

Post by nickjj »

rawoke083600 wrote: post #292
nickjj wrote: post #257

Earlier quoted context omitted.

Some of those things are pretty easy to solve. For example checking upcoming card expirations is running a DB query on a daily background / cron job that returns cards where the expiration date 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 h…

>It's like 3 lines of code with most popular web frameworks We doing DB/cron queries now with "web frameworks" ? :O

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

Post reply on HN