[pc]

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

[JoshTriplett]

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.

[cabalos]

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.

[gnicholas]

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

[conductr]

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.

[edoceo]

I have PayPal subscriptions billing, it's 2.9% + $0.30/txn - this might be slightly less than Stripe now?

[posguy]

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.

https://en.wikipedia.org/wiki/Durbin_amendment

https://usa.visa.com/dam/VCOM/download/merchants/visa-usa-in...

[Ziggy_Zaggy]

Good information - thanks for the reply.

[pc]

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

[robertlagrant]

> It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained.

This seems a little unlikely. Unless the billing side of things was too complex? :)

[Dylan16807]

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!