(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…
Thank you for taking the time to explain and write this up.
While you are here:
Any update on when Stripe will be available in South Africa ? We really need some alternatives to PayPal.
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 h…
>It's like 3 lines of code with most popular web frameworks
We doing DB/cron queries now with "web frameworks" ? :O
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…
> 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 r…
> 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? :)
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.)
> I'm sorry that it feels that way.
I think it is that way, and this is an attempt to make it feel a different way.
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…
> 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 r…
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!
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…
You often expect this service to be included with a payment processor that is already charging you for transactions.
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
It's great that Stripe supports this so easily.
We wanted to move ~300 credit card details from SagePay to Stripe. SagePay had a minimum admin fee of 2000GBP in order to do this, and no amount of negotiation could shift it.
If anyone's had a better deal from SagePay - let me know.
Is there any downside (other than a little more work for the implementer) to just using their main payment processing API, and to implement subscription billing with a cronjob? This is what sr.ht does [1], at least as of a year ago. If doing it manually now means saving a bunch of money, seems like a no-brainer. [1] https://cmpwn.com/@sir/103074952842876982
We did that for a couple of SAAS. In fact, we even extracted this out to an internal library with a web UI. If anyone is interested, let me know and I’d be happy to open source it. It’ll have to be run in its own server and process. But for full disclosure, my latest project just bit the bullet and accepted the extra 0.5%. Wanted to see how it goes. Could always switch if I found the need.
Yep, heard loud and clear. We've been investing a lot in USD (and other currency settlement) in various markets (and actually just released it in Singapore). We're working on it in Australia too.
won’t this eat into your revenue since you won’t make money on the exchange ?
People like GP who's revenue is eaten into by it not existing switching away from Stripe would also eat into its revenue.
(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…
hi Patrick,
For some reason your designers have decided that your website should pick a language based on the ip address.