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?)
Relevant subthread: https://news.ycombinator.com/item?id=36805571
Show HN: Iso20022.js – Create payments in 3 lines of code
11–20 of 139 posts
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#12as 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?)
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!
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#13Three lines with payloads minified?
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)
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#14It’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.
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#15Hey 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!
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).
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
iso20022.createSWIFTCreditPaymentInitiation(paymentInstructions);Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#16How about receive payment notification via webhook ? Is there standard ?
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#17as 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?)
Relevant subthread: https://news.ycombinator.com/item?id=36805571
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
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#18in what scenario is iso20022 payments used? would this be for forexample automating payroll?
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#19I 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.
Re: Show HN: Iso20022.js – Create payments in 3 lines of code
#20as 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?)
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.