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
This is a huge understatement! Its very painful. It sounds easy, but there are so many end cases with the calendar alone! Let along discounts, prorating, cancelations, etc.
It sucks to become dependent on providers for this service, but it also sucks to have crappy recurring billing.
> 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 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).
> 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.
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.
I'm not reducing, this is what recurring billing is. The relevant issues include cancellations, pro-rata refunds, card expiry, calendar calculations (always fun), etc. These are not rocket science.
Handling of tax has to happen on any payment and is not an issue specific to recurring billing/payments. It obviously brings in its own set of issues, the biggest of which is the multiplication of requirements if you want to comply with the rules of many countries, as you point out.
If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems".
It's also not something that a service like Stripe will handle for you to a useful degree.
Edit: And dunning.
Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development.
And pro-rata'd subscription changes. And pro-rata'd refunds.
You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates.
We pay Paddle 5% of every subscription transaction for a reason.
But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.
> If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems".It's also not something that a service like Stripe will handle for you to a useful degree.
And yet it is a key part of the engineering problem that has to be solved, which moves it away from "not one of the complicated problems" and being "quite standard work" (the original post I was replying to, disagreeing with the thrust of their post).
Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development.
We've discussed testing payments before (GoCardless last time) and are in agreement that it can be improved. I've seen no way to test Stripe's dunning.
You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates.
And yet last month I worked with a SaaS which implemented recurring billing a few years ago, and can't get it right. They overlooked pro-rata entirely (which at least prevented edge cases) and dunning didn't work. They aren't the first either.
Which is why, when I see the mess people have made of it, I disagree with the original assertion.
But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.
It is an accurate comparison when answering "[Managing recurring billing] is not one of the complicated problems". We have merchant of records, we have profitable subscription companies like Recurly, Chargify and Chargebee. If it (and keeping up with a changing landscape) wasn't a significant problem for businesses then more would roll their own rather than outsource (and of those that have, get it right).
Reading your other comments on this page, we agree on many more things than we disagree. Here we likely disagree on semantics: what's an engineer's role; what's simple vs complicated? Great to correspond again.
Possibly we're just talking slightly at cross-purposes here, yes. I was intending to comment on the idea that the additional features that a service like Stripe offers for recurring billing management were difficult to implement directly -- the scheduled charges, pro-rating of changes, retries on failure, etc. In other words, the extra features that Stripe is apparently now going to be charging everyone for.
I don't think this stuff is particularly difficult to get right, having essentially done it myself in the past. Indeed, I've never actually worked anywhere that directly integrated with a single payment service without at least some degree of isolation/abstraction. (This is also why features like Stripe's recent customer portal are of little interest to us. Directing a customer there to update their details means they can only change them to something else we use Stripe for, but we don't want to be locked into Stripe like that, we want to offer each customer the full range of payment options we support wherever they are.)
The harder things to implement these days, at least in our experience at my own businesses, are the mechanical integration with all the different payment schemes, where you really do need a specialist service that provides the required access, and the tax and compliance issues, where the ever-changing landscape makes outsourcing this aspect of the setup more and more attractive. But you can get the first of those with many different services and you need something like a merchant of record or one of the dedicated tax management services for the second.
Presumably for some types of business fraud prevention is also a big deal, but again you'd get the basic checks with many services that let you charge a card or the like, and I'm sceptical about how much these fancy AI-based big-data-crunching models are really improving performance. In any case, for those of us in more niche markets, there is little scope for someone to defraud us significantly anyway and the risk of anything bad happening has been very low over the years.
So in the end, with the way the industry seems to be moving, I can see an argument for just outsourcing basic payment processing and then handling the automation and tax/regulatory stuff in-house (for example, if you already have a dev team to implement what you need and you're already set up in some other way on the tax/regulatory side). I can also see an argument for outsourcing just about everything to a merchant of record service. But I think the case for the middle ground model that most of the payment services we've been using over the past decade or so operate is getting weaker all the time. And since they all keep forcing us to do major integration work just to keep the same functionality we already had from breaking and putting up their prices, I can't honestly say we've been feeling a lot of loyalty to any of them lately, hence our ongoing investigations of possible alternatives that I mentioned in other comments.
In my experience, it should be no more difficult than sending recurring emails. You should have all the data (PaymentProcessorCustomerID, LastBillingDate, etc), run it like you would a email with a retry queue.
In the example you gave, how would stripe billing solve that? This seems like you'd need some kind of manual interaction regardless?
For all the end cases, you manually handle them until they happen with enough frequency to require automation. A simple recurring billing system is absolutely fine for most businesses, and as you scale you can add more bells and whistles to it.
I think you're right in this case. I haven't looked at the problem in about 10-15 years (before Stripe had recurring). I remember there being a ton of end cases I had to deal with. We ended up going with Recurly due to it.
