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

71–80 of 139 posts

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

#71

Post by svapnil »

mremes wrote: post #68
svapnil wrote: post #46

Earlier quoted context omitted.

That does sound really really fun.. What's great about XML is that free text / bank specific fields can be handled elegantly with XML's extensible structure. That is why I think ISO20022 is here to stay. That said, this library is made to be extensible. One day I think it will even be able to encapsulate any type of bank. For example, imagine bofaISO20022.createACHPaymentInitation or something

What XML has to do with bank-specific messages that have to be parsed and processed? It’s just a markup format.

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

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

#72

Post by ldjb »

mremes wrote: post #68
svapnil wrote: post #46

Earlier quoted context omitted.

That does sound really really fun.. What's great about XML is that free text / bank specific fields can be handled elegantly with XML's extensible structure. That is why I think ISO20022 is here to stay. That said, this library is made to be extensible. One day I think it will even be able to encapsulate any type of bank. For example, imagine bofaISO20022.createACHPaymentInitation or something

What XML has to do with bank-specific messages that have to be parsed and processed? It’s just a markup format.

It's the extensible nature of XML that gives it an advantage. You can add custom elements and attributes whilst conforming to the base schema.

Granted, XML isn't the only format where this is possible. You can sort of achieve it with JSON, though XML's namespace system helps deal with name collisions. Adding bank-specific messages wouldn't be possible (or would be difficult) with fixed-column formats, for example, unless they had been specifically designed to be extended.

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

#73

Post by hanniabu »

mrloba wrote: post #36

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

Would be nice if people just adopted ethereum

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

#74

Post by pseudocomposer »

svapnil wrote: post #46
mrloba wrote: post #36

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

That does sound really really fun.. What's great about XML is that free text / bank specific fields can be handled elegantly with XML's extensible structure. That is why I think ISO20022 is here to stay. That said, this library is made to be extensible. One day I think it will even be able to encapsulate any type of bank. For example, imagine bofaISO20022.createACHPaymentInitation or something

You can have extensible structure and fields with JSON Schema, gRPC, Cap’n Proto, etc. There’s nothing XML-specific about that.

The only thing XML gives you over any of those formats is unstructured mixing of text and data, which is more a foot-gun than anything. Oh, and of course, being significantly more verbose.

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

#75

Post by cyanydeez »

svapnil wrote: post #71
mremes wrote: post #68

Earlier quoted context omitted.

What XML has to do with bank-specific messages that have to be parsed and processed? It’s just a markup format.

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

Custom schema means nothing against improper implementation

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

#76

Post by actionfromafar »

pseudocomposer wrote: post #74
svapnil wrote: post #46

Earlier quoted context omitted.

That does sound really really fun.. What's great about XML is that free text / bank specific fields can be handled elegantly with XML's extensible structure. That is why I think ISO20022 is here to stay. That said, this library is made to be extensible. One day I think it will even be able to encapsulate any type of bank. For example, imagine bofaISO20022.createACHPaymentInitation or something

You can have extensible structure and fields with JSON Schema, gRPC, Cap’n Proto, etc. There’s nothing XML-specific about that. The only thing XML gives you over any of those formats is unstructured mixing of text and data, which is more a foot-gun than anything. Oh, and of course, being significantly more verbose.

A niche thing maybe, but XML has comments, which I appreciate.

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

#77

Post by actionfromafar »

hanniabu wrote: post #73
mrloba wrote: post #36

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

Would be nice if people just adopted ethereum

Then banks would adopt ethereum. And use Iso20022.

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

#78

Post by catapart »

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…

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!

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

#80

Post by inkyoto »

mrloba wrote: post #36

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

Other than bank specific custom extensions, another problem with this standard is its scope and, consequently, its size – it is vast. ISO 20022 breaks down into over 700 what they call «messages» that cover pretty much everything, from the interbank settlements to bank-to-customer account statements.

Another challenge is that different banks may use slightly different versions of the standard messages that are enunciated via the implementation specific concrete XML namespace in the xmlns attribute of the message envelope.

Overall, ISO 20022 is an improvement over MT940/MT942 and friends, although it is not easy to use.

Post reply on HN