171–180 of 331 posts
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. Not affiliated to CB - just a happy customer!
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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.)
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…
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.
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).
Earlier quoted context omitted.
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.
Would this thread have become #1 with this title? The title used to read something like 'Stripe charges 0.5% more for subscriptions'. edit: I would understand if this was actually the title of the page. But it isn't either.
Earlier quoted context omitted.
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.
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…
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.