Comment by dawidloubser | Hacker News Reader

Comment by dawidloubser | Hacker News Reader

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.

The remaining 675,000 lines of code are to:

- Perform Risk / Fraud scoring to decide whether you want to, indeed, process this payment.

- 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.

- Refund, void or reverse previous payments.

- Create the necessary accounting entries in order to do settlements / settlement reports for your customers.

- Etcetera

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.

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.

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.

So true. And next to the 675,000 lines of business logic that you describe, you'll need an additional 133,700 lines of boilerplate code that:

- ensures all operations are atomic. You can't just post to an API and then insert something in your database: that's a guarantee to have payments in one place and not the other.

- has some way to retry on failure: your average job-queue with exponential backoff is quite certainly still too naive.

- has full, secured and guaranteed audit logs. That have all the data needed for an audit, but also not too much. You chose to not go for the Event Sourced Architecture because of Reasons? Good luck bolting it in now.

The hard part isn't generating some pain.001.001.03 (yes, that really is the name for the SWIFT Payments Initiation in iso-20022) format. The hard part is everything else.

Add some lines for managing the bank's security requirements: signature, encryption and authentication.

If you work with multiple banks, like many corporates or fintechs, multiply many of these lines by the number of banks you work with.

Even before starting to code anything, a big part of the job is obtaining the documentation from each bank and specifying the integration for each bank.

For instance, for the same payment scheme, different banks require different maximum payments per file or payload, or maximum payment file or payload size.

More things to consider in this high-level article https://www.numeral.io/blog/bank-payment-integrations-challe...

Thanks for sharing Matthieu - you know a lot about the banking system. I previously worked at Modern Treasury, so I'm also very familiar with bank integrations.

If you had the time, would love to talk more about this - my email is svapnil@woodside.sh and I'd love to get in contact with you

I completely agree. When I first saw some of the issues ( in US ), my first reaction was that of disbelief. I simply could not believe this is the way it is set up.

If US has any defense, it is that it is not alone in this craziness as almost every bigger power center carefully manages its domain to ensure it remains a relevant player. To put it simply, there is too much money in managing different pipes.

At this point though, short of complete collapse necessitating full rewrite of the existing payment systems, standardization will not happen. ISO itself is a convoluted mess with one real benefit of using standard XML.

The government has typically abdicated payments to various proprietary networks and big banks in the US. Try getting your hands on the NACHA spec for our glacial "direct" deposit standard.

We also have no standard way of letting users authenticate to their bank to download transactions. Once you get logged in there is usually a way to get OFX (QFX) files but the process is manual. I happened on the European open banking documentation the other day...jealous.

Reply on news.ycombinator.com