Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Iso20022.js – Create payments in 3 lines of code

iso20022js.com

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#111

Post by robertlagrant »

Waterluvian wrote: post #30
robertlagrant wrote: post #26

This is a nice looking website, and I can imagine this being a really useful hook into consulting work. Some thoughts: - replace strings with enums where possible. E.g. "USD" should be from an enum - this sort of data-interop library could maybe be written in a configuration language that it uses to generate libraries for different languages - a glossary would be really helpful - a list of banks who've adopted this I…

This is one place where interop between JS and TS gets prickly. If you envision this as a Typescript library, strings are much more ergonomic, so long as you’ve got a union type for all the variants. But if you want it to be decent for non-TS, you pretty much have to concede that compromise and use an enum/object. Note how this is a typescript project and leverages a type for currency that comes from a common library…

That's a fair point. The thing I'd be more thinking about is: can I get a list of currencies? I get I have type safety, but if I want to present the user with a list of valid currencies, can I do that from the type system? Enums can make that sort of thing very straightforward.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#113

Post by [deleted] »

bilekas wrote: post #85
cyanydeez wrote: post #75

Earlier quoted context omitted.

Custom schema means nothing against improper implementation

This has me a little dumbfounded as either really profound or slightly misguided. How do you mean? As I am reading this you think a custom schema wont effect an implementation, but how do you expect to implement an external service (API for example) without the required defined schema. That's kind of the definition of a schema in this scenario. Extending the schema might be another thing. But implementation can't wor…

[deleted]

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#114

Post by dawidloubser »

cuu508 wrote: post #87
svapnil wrote: post #71

Earlier quoted context omitted.

Banks add their own features to the spec - imagine they want to add a new "Bank only" attribute that makes their XML schema differentiated and better in some way. ISO20022 / XML allows this to be possible without breaking anything. In the past payment formats used to be fixed width text files - impossible to change or improve functionality for

> impossible to change or improve functionality for You have to think inside the box! What if, say, instead of lastname "SMITH" we used "SMITH,FEE: 5.65"

Excellent example clearly from a fellow soldier from the trenches!

As somebody who has built several instances of both payments- and travel booking systems, I have seen things in systems that "adhere to published schemas" (often because the schemas were beastly, design-by-committee hellscapes of extensibility) that defy belief.

While there is a strong argument to be made that strict type systems in programming langues like Haskell and Rust make it very difficult to play outside of the rules, this is unfortunately not the case in practice when it comes to APIs - both at present where you have a JSON Schema or Open API spec if you are lucky, and in the past (XML Schema, SOAP).

I wish that the ability to express a tight, fit-for-purpose schema or API actually resulted in this commonly being done. But look at the average API of any number of card payment gateways, hotels, or airlines, and you enter into a world where each integration with a new provider is a significant engineering undertaking to map the semantics - and the errors, oh the weird and wonderful errors... to the semantics of your system.

I am glad to work in the space-adjacent industry now, where things are ever so slightly better.

(Note the lack of sarcastic emphasis - it really is only _slightly_ better!)

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#115

Post by dawidloubser »

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.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#116

Post by bluepizza »

catapart wrote: post #53

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…

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.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#117

Post by j16sdiz »

robertlagrant wrote: post #26

This is a nice looking website, and I can imagine this being a really useful hook into consulting work. Some thoughts: - replace strings with enums where possible. E.g. "USD" should be from an enum - this sort of data-interop library could maybe be written in a configuration language that it uses to generate libraries for different languages - a glossary would be really helpful - a list of banks who've adopted this I…

> - replace strings with enums where possible. E.g. "USD" should be from an enum

Believe it or not, many bank use custom/non-standard currency code internally.

I agree enum can be used for SWIFT, but it need to be string to be used internally in many bank.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#118

Post by berkes »

dawidloubser wrote: post #115

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…

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.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#119

Post by berkes »

svapnil wrote: post #59
catapart wrote: post #53

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…

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 thei…

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

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#120

Post by Waterluvian »

robertlagrant wrote: post #111
Waterluvian wrote: post #30

Earlier quoted context omitted.

This is one place where interop between JS and TS gets prickly. If you envision this as a Typescript library, strings are much more ergonomic, so long as you’ve got a union type for all the variants. But if you want it to be decent for non-TS, you pretty much have to concede that compromise and use an enum/object. Note how this is a typescript project and leverages a type for currency that comes from a common library…

That's a fair point. The thing I'd be more thinking about is: can I get a list of currencies? I get I have type safety, but if I want to present the user with a list of valid currencies, can I do that from the type system? Enums can make that sort of thing very straightforward.

Yeah. The way I handle this is to make an array (or set) of those strings and then define a union type of that array.

Which is basically just an enum of my own invention. But after years of trying different things, I find this is the most practical. Objects are uncomfortable. TS enums really suck, IMO.

So maybe we’re actually in agreement. And to an extent can just have both: autocompletable, legible strings without another import or object. And also an iterable collection of the variants.

Post reply on HN