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

How ACH works: A developer perspective (2014)

engineering.gusto.com

Post reply on HN
Print view View original

111–120 of 226 posts

Re: How ACH works: A developer perspective (2014)

#111

Post by gaius »

dcow wrote: post #36
tomc1985 wrote: post #14

Earlier quoted context omitted.

They already have an API, it's called FTP or SFTP or whatever.

I don't know why everyone thinks they need an API to reimplement (poorly) basic unix functionality that's been around be for years.

But but rewrite all the things in node.js!! Don't worry about understanding the file format, which is well established, or what the users of the file are actually doing with it, also well established, the important thing is node.js!!!

Frankly once they hear it's node.js the users should be bowing down to worship!!!!

Re: How ACH works: A developer perspective (2014)

#112

Post by kennydude »

djsumdog wrote: post #95
mdip wrote: post #45

I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…

My first job in 2005 was to take over an ACH processing system that was written for our company. It was all in Perl. :-P ACH format is super weird .. tons of lines with 99999 on them as separators. And yes, we had to go through a bank to do any ACH transactions. They shipped us a router that setup an IPSec tunnel and it had a backup ISDN connection on it as well. I wish ACH was more accessible. In many other countrie…

In the UK we have "faster payments" and money these days typically appears in about 15 minutes or so

Re: How ACH works: A developer perspective (2014)

#113

Post by Karrot_Kream »

joshribakoff wrote: post #87
corndoge wrote: post #28

Earlier quoted context omitted.

why use a huge codebase like node for such a simple security critical task

How else do you suggest you standup a sftp that cannot leak data even if the password is compromised? I'm all ears. Node is a runtime by the way and huge in what regard? The Linux codebase is also large.

Seconding what kalleboo said, setting directory permissions has been a staple of file-sharing for decades. Setting up a node server to block read-access seems incredibly byzantine.

Re: How ACH works: A developer perspective (2014)

#114

Post by fweespeech »

tinbad wrote: post #62
mdip wrote: post #45

I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…

I was just going to say, working for one of the largest destributors in the world, this is still how many large corps buy stuff: by downloading a catalog through FTP and sending the order with XML. I know, shocking but not everyone is Amazon.

You may want to look at MWS then. It's the same batch processed feeds and XML over https instead of sftp.

Re: How ACH works: A developer perspective (2014)

#115

Post by teddyh »

joshribakoff wrote: post #90
voltagex_ wrote: post #47

Earlier quoted context omitted.

Wouldn't FileZilla have been happy with a fake blank directory response?

Yeah I added that but the particular node sftp implementation I used from github just simply didn't work with FileZilla. Only the command line. Don't know why.

Whenever someone says “from github”, I mentally replace it with “from some random guy on the street” to give it its appropriate intuitive feeling.

Re: How ACH works: A developer perspective (2014)

#116

Post by zkms »

jackgavigan wrote: post #42

The UK's Faster Payments system does same day (often less than an hour) inter-bank transfers for up to £250,000. http://www.fasterpayments.org.uk/about-us/how-faster-payment...

It's also a "push" system (and not a "pull" system like ACH) which has serious advantages -- you can send money to anyone given their sort code and account number, and those numbers do not need to be kept private.

With ACH if you have someone's routing number and account number you can pull money from their account without them needing to authorise it.

Re: How ACH works: A developer perspective (2014)

#117

Post by tannhaeuser »

FWIW, Swift (the company behind the interbank payment system) has been developing and pushing ISO 20012 as an XML-based long term replacement for their Swift message format, though it's not designed as a replacement for ACH.

For that, there was HBCI years ago (also XML); don't know if it's used much still.

Re: How ACH works: A developer perspective (2014)

#118

Post by Rjevski »

kennydude wrote: post #112
djsumdog wrote: post #95

Earlier quoted context omitted.

My first job in 2005 was to take over an ACH processing system that was written for our company. It was all in Perl. :-P ACH format is super weird .. tons of lines with 99999 on them as separators. And yes, we had to go through a bank to do any ACH transactions. They shipped us a router that setup an IPSec tunnel and it had a backup ISDN connection on it as well. I wish ACH was more accessible. In many other countrie…

In the UK we have "faster payments" and money these days typically appears in about 15 minutes or so

Even less that that. Yesterday I tried sending money from Starling Bank to Monzo and it literally took a few seconds.

Re: How ACH works: A developer perspective (2014)

#119

Post by joshribakoff »

EpicEng wrote: post #101
joshribakoff wrote: post #97

Earlier quoted context omitted.

No. I'm referring to an API to query data in realtime instead of batching the entire freaking database and then having out dated snapshot of the data

>Because it didn't work in FileZilla, they didn't want to use it Sounds like they didn't need much if any of what you did. They wanted X and you gave them Y. Y would require them to change the way they worked. Did they need query capability? Seems like they didn't and SFTP would have suited them better. Honestly sounds to me like you went for an overly complex solution where something simple would have done just fine…

Our company and their company have a common customer. Neither of us need each other we want to make our customer happy. Customer would be happiest with realtime data but company B wants to send snapshots via sftp. So I setup an endpoint that speaks sftp. They even told me to "do something" to make it secure. Then they complained I used a port other than 22 and that it only worked on the command line. It sounds like the problem is the other company doesn't want to do any work / wants to send the file manually. I don't see how I went for an overly complex solution. I attempted to do exactly what they asked and they moved the target so of course I missed. In fact it's this company that is just trying to avoid doing any programming. But that comes with the territory. I respect your opinion but disagree with you

Re: How ACH works: A developer perspective (2014)

#120

Post by yellowapple »

kyrra wrote: post #75
donatj wrote: post #57

Earlier quoted context omitted.

Is it sftp or ftps? They're very different things and I am fairly certain it's the latter.

Most payment vendors are on SFTP at this point. Very few still use only FTPS. But then they do silly things with SFTP, like requiring both a password and the ssh key.

"like requiring both a password and the ssh key."

That doesn't sound that unreasonable. Both satisfy the "something you know" and "something you have" portions of multi-factor authentication (respectively).

Considering that this is money on the line, the idea of banks actually taking security seriously is actually refreshing. Too bad they don't seem to apply those standards to their customers.

Post reply on HN