[HN Gopher] Show HN: Iso20022.js - Create payments in 3 lines of...
___________________________________________________________________
Show HN: Iso20022.js - Create payments in 3 lines of code
Author : svapnil
Score : 126 points
Date : 2024-08-05 17:55 UTC (5 hours ago)
(HTM) web link (www.iso20022js.com)
(TXT) w3m dump (www.iso20022js.com)
| svapnil wrote:
| 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!
| franciscop wrote:
| Since you do say it in HN tagline, what are the "3 lines of
| code"? I can only see 43 LoC in the landing page. A tool to
| help massively with payments is always welcome of course, but
| if this is really 43 lines instead of 3 it'd feel like shady
| marketing (no judgement until there's a reply/clarification).
| tootie wrote:
| I mean, it's 3 statements with like 40 lines of JSON options.
| Debatable what counts as a LOC, but it's still pretty
| impressive.
| prettyStandard wrote:
| I imagine they are counting object literals as one line of
| code, I'm inclined to agree. Maybe they could have said in "3
| statements of code".
|
| > import { ISO20022 } from 'iso20022.js'
|
| > const iso20022 = new ISO20022({ / _..._ / });
|
| > const creditPaymentInitiation =
| iso20022.createSWIFTCreditPaymentInitiation({ / _..._ /});
|
| > console.log(creditPaymentInitiation.toString());
|
| Now are we counting the import and not counting the log
| statement, or are we counting the log statement and not the
| import?
|
| I'm not too worried about it.
| jerf wrote:
| It's the import, the "const iso20022 = new ISO20022" line,
| and the "const creditPaymentInitiation =
| iso20022.createSWIFTCreditPaymentInitiation". The big data
| chunks are being counted as one line.
|
| I will admit I'm usually very skeptical about "Do X in Y
| line" claims because usually you can do anything in one line
| by shoving the entire codebase behind a "DoIt()" call. But
| I'll actually give them this one. I'm not even worried about
| the data taking up so many lines as clearly the data is
| necessary. If they were full of mandatory function calls or
| something I'd ding 'em too, but they're not, it's just the
| data you need.
| franciscop wrote:
| If it was free text content I'd agree, but this being
| configuration code where you need to be very precise on the
| key names and values, possibly reading some docs and
| consulting multiple sources per line, I would not count
| this as 3 lines... 3 simple steps sure, but calling that 3
| lines is not being honest IMHO.
| NoboruWataya wrote:
| You import the library, initialise an object and call its
| method. I think it's fair enough to call that example three
| lines of code.
|
| The bigger question of course is what do you end up with.
| Clearly that method call isn't going to actually send an
| instruction to your bank to debit your account and credit
| somebody else's. I guess `creditPaymentInitiation` is an
| object that has can be converted to a properly formatted
| message that can then be sent to your bank using an external
| tool?
| cess11 wrote:
| I'd bet the .toString() method returns an XML payload you
| can shove into your API call when you've configured a
| client for it.
| svapnil wrote:
| Yup - see
| https://docs.iso20022js.com/quickstart#step-4-send-the-
| payme... if you wanna see how that's done
| runlevel1 wrote:
| It'd be more accurate to say 3 steps, but I see where they're
| coming from: // 1. Import import {
| ISO20022 } from 'iso20022.js' // 2. Instantiate the
| sender const iso20022 = new
| ISO20022(initiatingPartyInfo); // 3. Send iso
| 20022.createSWIFTCreditPaymentInitiation(paymentInstructions)
| ;
| svapnil wrote:
| Thanks for checking out what I'm working on Francisco -
| you're right - expanding all the data models here increases
| the LoC. The objective of iso20022.js is not to be overly
| simplified, but rather offer the best way to interface with
| the ISO20022 standard. That's a big reason for the large
| payloads - no obfuscation.
| andrewshadura wrote:
| Support SEPA and its national variants.
|
| Support bank statements.
| ppbjj wrote:
| Three lines with payloads minified?
| svapnil wrote:
| haha, yes.
|
| fiat bank payments require a lot of information to be send
| correctly, for better or for worse. this library conveniently
| exposes the elements needed to send a payment, as per the most
| widely used standard available (iso20022)
| yawnxyz wrote:
| as an average joe, I'm curious about how all this works / what
| else you need to make it work (what's a banking partner, etc?)
| toomuchtodo wrote:
| Relevant subthread:
| https://news.ycombinator.com/item?id=36805571
| svapnil wrote:
| thanks for sharing - this is really helpful context.
|
| ISO20022 is the XML standard to send payment instructions,
| and this library conveniently exposes it's models in
| Typescript format. It seems like understanding what ISO20022
| is is super important, so I'll spend some effort educating
| people on what this is
| toomuchtodo wrote:
| Additional context below that might be helpful for
| educational purposes.
|
| https://evrim.zone/blog/knowledge/iso_20022_pain_001
|
| https://news.ycombinator.com/item?id=36810744
| svapnil wrote:
| thanks for the feedback. companies that need to
| programmatically send payments via bank need a corporate bank
| account that allows them to send programmatic payment
| instructions. i'll make this more clear in the docs!
| cess11 wrote:
| It's basically a collection of API standards for common
| messages to and between financial institutions. If you need to
| communicate a lot with your bank or banks generally, then
| you'll probably automate it through this standard, at least in
| Europe, I'm not sure about adoption elsewhere. Things like
| reading accounts, registering transactions, stuff like that.
| You can, for example, build a background job that does monthly
| consolidation of accounts against a pile of payment providers
| your customers use.
|
| If you enjoy SOAP you'd feel right at home and likely have
| better tooling foundations already, if you don't you probably
| want a library like this one, at least when they've implemented
| SEPA support.
| LiamPa wrote:
| It's a shame it's probably going to take another 10 years before
| any of the banks actually migrate to ISO20022 (if it ever
| happens) SwiftMT conversion software is currently the big sell so
| they don't have to rewrite / build everything they already have.
| cess11 wrote:
| In 2018 I implemented a software client that sent SEPA pain
| messages to the Luxembourg branch of a swedish bank. I don't
| know where you live, but at least in Europe this standard seems
| somewhat broadly adopted.
| LiamPa wrote:
| SEPA has always been ISO20022, SWIFT (US) is now following
| revskill wrote:
| How about receive payment notification via webhook ? Is there
| standard ?
| svapnil wrote:
| Thanks for asking revskill, payment notifications are actually
| a different payment file, called a Payment Status Report file
| (pain.002). This is the industry standard
|
| Instead of webhooks, a developer would poll an SFTP directory
| for an unique PSR file to ingest. Eventually, iso20022.js
| should support ingesting PSR files and provide an interface for
| using them.
| victorbjorklund wrote:
| in what scenario is iso20022 payments used? would this be for
| forexample automating payroll?
| samstave wrote:
| > in what scenario is iso20022 payments used
|
| I wanted to know this as well - specifically sms based payments
| if its so easy to wrap payment calls... found this:
|
| ---
|
| ISO 20022 is a global standard for electronic data interchange
| between financial institutions, enabling efficient and secure
| exchange of financial messages. It is widely used in various
| payment scenarios, including:
|
| * Cross-border payments:
|
| ISO 20022 facilitates international transactions by providing a
| common language for financial institutions to communicate.
|
| High-value payments: It is used for large-value transactions,
| such as wholesale payments, securities settlements, and
| treasury transactions.
|
| Retail payments: ISO 20022 is also used for retail payments,
| including credit transfers, direct debits, and e-payments.
|
| Real-time payments: It supports real-time payment systems,
| enabling fast and efficient transactions.
|
| * SMS-based payment initiation:
|
| An SMS can be used to initiate a payment, with the payment
| details (e.g., amount, recipient) encoded in an ISO 20022
| message. The message would then be sent to a payment processor
| or financial institution for processing.
|
| Mobile payment apps:
|
| Mobile payment apps can use ISO 20022 for payment processing in
| the background, while the user interacts with the app via SMS
| or a graphical user interface.
| graypegg wrote:
| I would've thought some sort of cryptographic signature would be
| used here, though maybe that's something done in a wrapper around
| this XML documents?
|
| Neat none-the-less! I always like this sort of actually-
| it's-simpler-than-you-think peek behind the curtain.
| MuffinFlavored wrote:
| What is an API/service we can use this encoder/serializer with?
| This seems like a part of the puzzle.
| svapnil wrote:
| Thanks for asking MuffinFlavored.
|
| There isn't something we are currently offering yet, althoug I
| wrote about how this works in the quickstart guide:
| https://docs.iso20022js.com/quickstart#step-4-send-the-payme...
| MuffinFlavored wrote:
| To expand for people who might not be as familiar, dropping
| the XML file on SFTP is common in fintec land.
|
| How do you get a response/know if your file processed
| correctly?
| 101008 wrote:
| Super stupid question, but this must have some kind of
| authentication, right? Where is that part?
| abimaelmartell wrote:
| That code sample is basically how ISO20022 works, you create a
| file with instructions to move money from one account to
| another.
|
| You would need to upload that XML to a bank to actually process
| the transaction.
|
| There are other formats like NACHA (US only), where you have to
| generate a text file with a pretty specific format, and upload
| that, often via sFTP to the Bank's server to process.
| robertlagrant wrote:
| 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 ISO standard might be
| interesting
| Waterluvian wrote:
| 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, and therefore
| doesn't have to do any of the work!
| https://github.com/Svapnil/iso20022.js/blob/main/src/lib/typ...
| svapnil wrote:
| Thanks for your feedback Robert!
|
| I think payments is an industry in general that is starving for
| the right information, so a free and open source package like
| this should have an abundance of information. I'll make sure I
| add it in.
|
| The configuration language sounds really interesting. What I
| think is special about this library is that it comes with all
| the Typescript furnishings one would need to have a powerful
| dev experience. The goal is to make it incredibly easy for a
| developer to use iso20022, not just another middle layer that
| obfuscates it
| robertlagrant wrote:
| It's a pleasure! To be clear, I meant that you could have a
| repository that contains all of the information in some sort
| of configuration language (or maybe in Typescript; I suppose
| that doesn't really matter) but you use that to generate
| multiple libraries; one for each language you might want to
| support. So a single codebase (or configuration base) could
| generate iso20022.js, iso20022.ts, iso20022.py, etc etc.
|
| It's not simple; it might just be an interesting distant goal
| to keep in mind.
| andyjohnson0 wrote:
| Slightly stretching the concept of "three lines of code". But it
| looks clean and self-documenting to this non-js developer. Nice.
| mrloba wrote:
| 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
| svapnil wrote:
| 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
| mremes wrote:
| What XML has to do with bank-specific messages that have to
| be parsed and processed? It's just a markup format.
| svapnil wrote:
| 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
| cyanydeez wrote:
| Custom schema means nothing against improper
| implementation
| ldjb wrote:
| 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.
| pseudocomposer wrote:
| 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.
| actionfromafar wrote:
| A niche thing maybe, but XML has comments, which I
| appreciate.
| hanniabu wrote:
| Would be nice if people just adopted ethereum
| actionfromafar wrote:
| Then banks would adopt ethereum. And use Iso20022.
| adamdecaf wrote:
| Are you planning on generating all (or a subset) of 20022
| messages? That's what we did for our Go package using 20022 for
| RTP. We added helpers for generating IDs and the signature
| sign/validate.
|
| https://github.com/moov-io/rtp20022
| svapnil wrote:
| Hi Adam, thanks for asking. Eventually, this library should be
| extensible to generate _all_ types of ISO20022 messages, but I
| 'm starting out with PAIN (Payment Initation!) messages. Would
| be super keen to add RTP - will reach out to you!
| philippta wrote:
| The difficult thing about payments is not necessarily formatting
| payment instructions to ISO20022, but rather setting up the
| underlying infrastructure like:
|
| - Shelving a Windows box in some authorized datacenter.
|
| - Going through a years long process of getting certified to send
| payment instructions to the scheme (e.g. SWIFT network).
|
| - Receiving a couple of USB sticks that contain certificates and
| signing keys.
|
| - Connecting to the schemes VPN.
|
| - Having all the legals in place.
|
| - And probably many more things I was never exposed to.
| enahs-sf wrote:
| Can you go into a bit more detail here. Seems like there are a
| lot of hurdles in place to preventing any random from just
| moving money around?
| svapnil wrote:
| Thanks for your comment phillippta, I agree with you there are
| a few big challenges in setting up payments companies need to
| deal with:
|
| 1. Security Adding vendors is a very scary thing for companies,
| rightfully so. Open source is great for this, because an NPM
| package is not a vendor.
|
| 2. Signing / Sending a Transaction iso20022.js doesn't deal
| with message sending yet. Best case there is a straightforward
| SFTP setup, which I've given instructions for here:
| https://docs.iso20022js.com/quickstart#step-4-send-the-payme...
|
| 3. Getting certified to send payment instructions. This should
| be the work of the module!
| phkahler wrote:
| >> I'd love to know what you think and importantly know about any
| improvements you'd like us to make!
|
| I think it's scary to do any finance related stuff using NPM
| dependencies. How large is your dependency tree?
| hdshjvgiogh wrote:
| That's what fintech is, one large dependency tree
| echelon wrote:
| With internal infosec, secinfra teams, compliance, and
| serious business contracts.
| svapnil wrote:
| extremely lightweight
| https://www.npmjs.com/package/iso20022.js?activeTab=dependen...
| thih9 wrote:
| Looks like twelve libraries total.
|
| Visualized: https://npmgraph.js.org/?q=iso20022.js
| catapart wrote:
| 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?
| svapnil wrote:
| 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.
| Quekid5 wrote:
| At the risk of sounding like an a-hole, there's a very
| important word there... "if".
| catapart wrote:
| 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!
| mkuznets wrote:
| XML Schema Definitions for all ISO20022 messages are public:
| https://www.iso20022.org/iso-20022-message-definitions
|
| There are tools that can turn the schema files into
| POJO/dataclasses/structs/etc in your language of choice,
| sometimes with proper data validation. Not sure about Typescript,
| but Java/Python/Golang definitely have those.
|
| It may very well be lost knowledge in certain ecosystems, but
| generating a valid XML based on the given schema is generally a
| solved problem. Not sure if the projects adds anything beyond
| that.
| svapnil wrote:
| Thanks for your comment mkuznets. I appreciate your input
| regarding XSD to class conversion - I agree that this is a
| super useful concept for sending ISO20022 files.
|
| I think there's always some ergonomic gap between these XML
| Schema generated classes and SDKs that developers are
| comfortable using. My intention for this library is for a non-
| payment developer to be able to interact with the ISO20022
| schemas, while being as true to the underlying models as
| possible.
| 38 wrote:
| Yeah exactly, with Go this should literally just be the type
| definition and that's it. You can do XML marshal, byte reader
| and http request with the standard library
| ultimatewhip wrote:
| So regarding ISO 20022 it is just a format for what is sent and
| read so each party have a common format to use (this is only
| partially true as institutions like making their own variant of
| it thats valid ISO 20022, think yaml vs json). Sending it is a
| completely different story, different financial institutions use
| different technologies for authentication and transport of these
| messages (SFTP, SWIFT, exotic custom stuff, etc..). My experience
| has not been in using ISO 20022 to send payments so maybe the
| payments space all use SWIFT or something.
| svapnil wrote:
| That's true, ISO20022 was designed to be extensible, meaning
| banks add their own crazy variants to it all the time.
| Currently iso20022.js can create a minimum viable working
| ISO20022 file, and in the future I'd love to support as many
| specs as we reasonably can
| guidedlight wrote:
| This makes sense to be used with Open Banking regimes, that is
| being mandated by government legislation.
| svapnil wrote:
| Government mandates are almost necessary to guide standard
| adoption. I saw this when I worked on UPI at WhatsApp
| CommanderData wrote:
| Nice work, can I ask how you tested this with SWIFT for example?
| Is there a development portal you need access to?
| neonate wrote:
| Github link: https://github.com/svapnil/iso20022.js
___________________________________________________________________
(page generated 2024-08-05 23:00 UTC)