I've worked at two companies in their payment systems. This post does a good job of mentioning many of the billing system challenges. I think it understates how difficult and important idempotency is to maintain at scale with multiple teams though.
Additionally, it didn't mention financial regulation changes. India had changes sometime in the last few years which required whole new systems built that were specific to India customers. One example of complexity is this: does the system apply to customers who are in India or does it apply to businesses who are in India (the owners might not be)?
He also did not mention fraud, which is basically uncollected spend that results in charge backs typically. If you get too many chargebacks, you'll get fined. If you get even more chargebacks, you'll get kicked off the card network and will no longer be able to accept cards within that network.
Post pay (customer gets the product and pays afterwards) models are subject to more fraud, uncollected charges, etc.
There's also the fun of dealing with downstream payment processors. I haven't worked with a processor or bank yet that was very reliable. Sometimes they'd return 500 http codes and then process a payment, requiring manual intervention. Sometimes that happens with files of payments because most banks deal with files for transactions.
> Additionally, it didn't mention financial regulation changes. India had changes sometime in the last few years which required whole new systems built that were specific to India customers. One example of complexity is this: does the system apply to customers who are in India or does it apply to businesses who are in India (the owners might not be)?
IIRC, I've read this is one of the reasons that systems like SAP are so popular. They might be an ugly monster from a technical perspective and seem overly complex, but they provide thoroughly tested implementations that handle all that stuff.
Hey @tablespoon, I'm one of the cofounders of Lago here.
Products like SAP do seem complex because of (i) the complexity of the billing problem and all the edge cases, (ii) they were not built with an API-first or engineer-first mindset
We're only at the beginning of the journey, but that's one of the reasons why we thought of open-sourcing our billing API, so that the work could be forked and tweaked to address edge cases if needed (no need to wait for SAP to update the product: and they will never prioritize small edge cases).
Also, it seemed to be no middle ground between 'Stripe Billing' (it's great for B2C Subscriptions) and billing systems that could address the millions of nuances of pricing between 'subscription' and 'usage-based' (most companies are a mix of both).
In the SAP R/3 family of products, there is also a component Factory Calendar (IMG -> SAP NetWeaver -> General Settings -> Maintain Calendar, transaction /SCAL) - a component that knows about all the various calendar systems incl. public holidays of the world and the dreaded leap years. If I remember correctly, it's customizable for each customer premise with respect to whether each day of the year is salaried or not.
This is a component classified as "basis technology" relied upon by many modules for billing (e.g. should a daily salaray be calculated in a country for a particular person? Should an invoice be considered "overdue" yet, based on the number of business days passed since issue? etc.).
I am the last one to defend SAP, but they do have an API first approach since some time, check this out: https://api.sap.com/products/SAPS4HANACloud/apis/all Also edge cases are taken care of, sometimes before you even small updates, via notes, mostly tax regulation changes. So yeah, for these things SAP is really made for. If you have a SAP account, you can check out, just to see how many changes are coming in: https://launchpad.support.sap.com/#/solutions/notesv2/?q=pol...
It's not like SAP/Oracle/etc have some magical power. They just pay attention to these things, build the product, THEN release the product. And initial releases are buggy just like most software.
So more agile players can get involved more quickly and entrench position.
Hey @Brystefor, I'm @Rafsark's co-founder.
We could have spent more time on idempotency, indeed.
We have not deep dived into the 3 other aspects you mentioned indeed, we're actually planning to
1/ open-source the articles and add additional challenges as they are mentioned
2/ open our roadmap based on these inputs as well
Thanks for sharing! Will ping you back here when it's live
PS: we had not thought of financial regulation changes indeed!
Oh, I didn't even realize this was a blog for an open source project. I assumed it was someones personal blog.
Two other things that you may want to consider:
1. PCI compliance. If you're involved in the storage of payment information, you may want to look into these regulations.
2. Regarding point 3 of your mission "...only integrating with specific partners to lock you in (e.g., Stripe Billing only working with Stripe Payments)...". I think there are many companies out there who want to integrate with more than a single payment provider (eg Braintree, Stripe, Adyen, etc) but run into this problem. It increases the cost of payments due to the "rent-seeker" charge method they use. Providing a design framework for how a single company could integrate with multiple providers could be beneficial. This is something I've considered trying to build, but I think it could fit with this initiative.
Hi @Brystephor! I'm Anh-Tho, one of the cofounders of Lago.
We're building an open-source alternative to Stripe Billing indeed, but we want to share our personal experience, hence the personal blog post.
We'll open our repo very soon and our public roadmap too. Thanks for adding the 2 points, we're working on 'a design framework for how a single company could integrate with multiple providers could be beneficial.' indeed!
Additionally, it didn't mention financial regulation changes. India had changes sometime in the last few years which required whole new systems built that were specific to India customers. One example of complexity is this: does the system apply to customers who are in India or does it apply to businesses who are in India (the owners might not be)?
He also did not mention fraud, which is basically uncollected spend that results in charge backs typically. If you get too many chargebacks, you'll get fined. If you get even more chargebacks, you'll get kicked off the card network and will no longer be able to accept cards within that network.
Post pay (customer gets the product and pays afterwards) models are subject to more fraud, uncollected charges, etc.
There's also the fun of dealing with downstream payment processors. I haven't worked with a processor or bank yet that was very reliable. Sometimes they'd return 500 http codes and then process a payment, requiring manual intervention. Sometimes that happens with files of payments because most banks deal with files for transactions.