201–210 of 331 posts
5¢ made sense, 0.5% is a parasitic approach, the tech stack and engineering costs them 0.1¢ per recurring transaction.
Sounds like you could clean up in this space at $00.001 per transaction!
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…
There have been comments elsewhere in the discussion that for folks with higher volume, we should be negotiating our fees. At what volume would you recommend companies reach out to your team to do so?
This is funny timing for us - we are currently looking at implementing a subscription service and were already looking at this price. Even so, 0.5% fee is miles away the cheapest option. (Most others want a fixed fee per month plus .8%). Is there reason for us to be scoffing at the new price? This is still a fraction even of processing the credit card.
Earlier quoted context omitted.
Yeah but isn't that just the way of the world? Processes can become simpler but at a certain point the complexity of the process is inherent and it would benefit you to employ an expert (individual or entity). You can build a house yourself, with your own hands, but why? I'm not an expert on the whole domain of payment processing but it seems to me there is a lot of non trivial problems inherent with taking payments.…
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. If you want subscriptions/recurring payments, stored payment methods and all the "fancy" stuff contemporary payment processors offer, you pay for it. If you just want to move money from A to B, it should be easy and it should be free. The only way…
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.
Earlier quoted context omitted.
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.
> 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…
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 subscription changes. And pro-rata'd refunds.
We pay Paddle 5% of every subscription transaction for a reason.
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?
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…
Earlier quoted context omitted.
We think charging a separate fee for our Billing product is fair, given comparable products in the market (say, Recurly or Chargebee) charge something similar. Copying what other people in the market are doing is the antithesis of what made Stripe so important when it first launched.
Processing margins are thin and they have a valuation ($36B) to justify, so they have to grow product margins where they can ("going upmarket"). Market realities/constraints.
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
Here's my anecdote of a different situation but with some similarities, where we couldn't get the data portability we wanted.
A few years ago I asked our Direct Debit provider if we could migrate customer subscriptions from our old business entity to our newly incorporated company version of the exact same business.
The old business entity was to be wound up as a complete transfer to the new one, the trading name was identical (transferred along with trademarks), and we were happy to keep the same DD provider.
The answer we got was no, each customer would have to enter their bank details and agree to the same terms again. From the customer's point of view, they probably wouldn't even notice it was a different business, because in a real sense it wasn't.
We decided this would lead to significant churn in customer subscriptions, and we couldn't afford it. It would be cheaper to maintain and administer the old business entity, for no business purpose whatsoever, just the sole purpose of continuing to receive the DD subscriptions, and pay them immediately in full to the new business entity.