Based on my experience of building several payment gateways, it is my opinion that it's pretty much always "3 lines of code" (which isn't true about this library - more like "3 steps") to post a payment, even to the nastiest acquiring or banking API.<p>The remaining 675,000 lines of code are to:<p>- Perform Risk / Fraud scoring to decide whether you want to, indeed, process this payment.<p>- Deal with the myriad of failure scenarios - including mapping them to your own system's error semantics - in a way that your customers can understand to reduce support calls.<p>- Refund, void or reverse previous payments.<p>- Create the necessary accounting entries in order to do settlements / settlement reports for your customers.<p>- Etcetera<p>Payments systems are perplexing to me: Nothing is a more obvious candidate for an absolute, standardised, commoditised piece of software in the same way that the global IP network routes packets - only in payments we are routing "promises" and our routes, and routing decisions, are in many ways much simpler.<p>Yet there are very few industries where this particular wheel gets reinvented as often as it does; each organisation convinced that it has its own unique approach to doing this absolutely standard, regulated "thing" - which, reductio ad absurdum, is just an expensive buffer in a network of pipes.<p>Hopefully open-source software will pave the way: TigerBeetle is an amazing start (distributed ledgers), and it's hopefully only a matter of time until the other components of a payments switch are freely available as open-source components with high-quality APIs.