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

121–130 of 139 posts

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

#121

Post by A4ET8a8uTh0 »

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…

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.

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

#122

Post by matthieu_bl »

berkes wrote: post #118
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 certai…

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

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

#125

Post by logicalmind »

LiamPa wrote: post #98
logicalmind wrote: post #97

Earlier quoted context omitted.

As of early next year, the Fed (US) will not accept anything other than ISO20022 messages on their networks. So any banks that are using Fed networks are required to use ISO20022.

I wouldn’t hold your breath

I work for a large financial institution and we've been migrating our Fed network processing to ISO20022. All financial institutions we work with, and vendors who process payments for fraud and such, are also doing so. I'm highly skeptical of the date, but it is going to happen.

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

#126

Post by iTokio »

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"

Yes, my son is really named BOB,FEE: -999999999.99

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

#127

Post by svapnil »

matthieu_bl wrote: post #122
berkes wrote: post #118

Earlier quoted context omitted.

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

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

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

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

#128

Post by svapnil »

inkyoto wrote: post #80
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 enunci…

I'd love to learn more about what you mean about the different xmlns's banks use - haven't seen that one yet.

The must know a lot about ISO20022 payments! I'd love to get in touch with you, if you can please shoot me an email @ svapnil@woodside.sh :)

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

#129

Post by svapnil »

andrewshadura wrote: post #67
svapnil wrote: post #2

Hey HN, My name is Svapnil Ankolkar and I've recently built iso20022.js, a library for creating ISO20022 payments in Typescript. The goal of this project is to be the easiest way to create, and eventually ingest, files in the ISO20022 standard, the defacto XML standard for bank payments. I'd love to know what you think and importantly know about any improvements you'd like us to make!

Support SEPA and its national variants. Support bank statements.

Would love to! It's next up on the roadmap for us - would love for you to check it out

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

#130

Post by svapnil »

ab_testing wrote: post #88

Hey this seems really interesting. But I have questions about this statement “. In order to transmit bank payments programatically, you must have direct transmission enabled with your banking partner. If you have any questions about this, don’t hesitate to reach out to us. So do we need to get this enabled on a per bank basis or a per account basis?

Hey ab_testing, this is done on a per bank basis. Perhaps bank by bank has different rules, so this is something they'd be best equip to answer.

If you have more questions, I'd love to help you out - please shoot me an email @ svapnil@woodside.sh

Post reply on HN