Hacker News Reader

Comment by catapart | Hacker News Reader

This looks pretty interesting, but my only experience with payments are black-box payment processors that expose an API, and services like Stripe that handle all of the institutional interconnection.

Could you help me understand who the target devs are for this library? I doubt it's someone like me, who would try to use it as a replacement for stripe before realizing all of the stuff I have to do outside of that and giving up on it. But maybe this is more for people who are doing heavy financial management anyway? Or am I just completely thinking about what this is wrongly?

View on HN

Hey catapart, thanks for your comment.

You're right. Accepting credit card payments over the internet is usually done handled by black-box third party payment processors.

Bank payments, like ACH, SWIFT, and others are usually built in-house by companies that move money at scale, like payroll providers, insurance companies, and other old school institutions.

As companies that do heavy financial management refresh their architecture and move to modern web servers and the like, they'll likely need to rebuild it from scratch. This is what iso20022.js plays a small part in - if they're building on Node this is a convenient library for them to use.

At the risk of sounding like an a-hole, there's a very important word there... "if".

Okay, gotcha. That makes sense! I was getting stuck on where I should send the end result, but I'm guessing if I were doing financial work, I would already have an endpoint from my partner financial institution that would expect this kind of data.

Thanks for the explanation!

> As companies that do heavy financial management refresh their architecture and move to modern web servers and the like, they'll likely need to rebuild it from scratch. This is what iso20022.js plays a small part in - if they're building on Node this is a convenient library for them to use.

Are companies do heavy financial management refreshing their architecture in node, javascript and typescript? And do they then rely on a library with one sole contributor?

Sorry if this sounds dismissive. I am actually afraid by the answer, because, having worked in fintech, I wouldn't be surprised if the answer is "yes, certainly some".

When I worked at the international (global markets, cross border payments) arm of a bank, we had to build SWIFT messages through code. Such a library is quite useful, especially since most places have legacy code that manipulates payment messages manually.

Black box payment processors and Stripe need libraries too.

Reply on news.ycombinator.com