Live data from Hacker News

Stripe migrates Stripe Subscriptions users to more expensive Stripe Billing

stripe.com

251–260 of 331 posts

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

#251

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

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.

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

#252
post #239
post #234

Earlier quoted context omitted.

Great -- if you reach out to support@stripe.com with "billing pricing extension" in the subject, it'll go to the right folks.

Does this billing price extension only apply to people who read HN, or will there be a newsletter informing all your customers of this new policy?

Yes, we encourage customers to reach out to us, and this policy has (before today) already been applied to them as well.

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

#253
post #205

Earlier quoted context omitted.

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

What you describe solves a problem that is not the problem that Stripe solves.

The problem you described is far, far simpler than the problem Stripe solves.

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

#254
post #93

(Stripe cofounder.) 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…

Cool! btw there's a small bug on the storage part of the pricing plan calculation. It shows 5,525 GB units but then the calculation is for 10,100 units.

Thanks for the heads up! We just pushed a fix.

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

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

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

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

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

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

This feels like New Coke.

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

#257

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…

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

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

#258
post #47

Earlier quoted context omitted.

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.

Stripe supports exporting PCI data like credit card details to other PCI Level 1[1] providers such as Recurly and Braintree. Data portability is a solved problem in this space - so there isn't a material risk of churn due to a migration like this. We recently went through the process and it was very easy. [1] - https://stripe.com/docs/security/data-migrations/exports

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.

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

#259
post #128

Earlier quoted context omitted.

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

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.

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

#260
post #222
post #121

I love how a Ycombinator company can quickly get a HN story title changed to censor the whole "price increase" aspect being debated here.

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…

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.

Post reply on HN