Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

81–90 of 226 posts

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

#81

I had an integrator request this so I stood up a nodeJS server that only implements upload, not download. This way if they leaked their own password, a malicious actor is limited to forging data, and no real data can be leaked. Because it didn't work in FileZilla, they didn't want to use it. Worked at another company that shuffled data between big name gyms & health insurance companies, it also used CSV files sent ov…

Reminds me of a time when I had to implement a parser for a certain kind of file to transfer money using an "API" provided by a financial institution in Asia. Yes we are using CSV too, also sent over SFTP. The file format is, unsurprisingly, ill-defined.

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

#82
post #57
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…

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

Actually it's the former, not the latter. Several banks I've worked with used SFTP.

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

#83
post #43

Earlier quoted context omitted.

Every bank I've worked with uses SFTP rather than FTP.

Just to be pedantic. SFTP (file transfer subsystem of SSH) or FTPS (FTP + TLS)? I mean, either is fine, I would just imagine that if it was FTP at some point, moving to FTPS wouldn't be unreasonable.

SFTP means exactly SFTP, and it's not ambiguous. FTPS is a completely different protocol.

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

#84

I had an integrator request this so I stood up a nodeJS server that only implements upload, not download. This way if they leaked their own password, a malicious actor is limited to forging data, and no real data can be leaked. Because it didn't work in FileZilla, they didn't want to use it. Worked at another company that shuffled data between big name gyms & health insurance companies, it also used CSV files sent ov…

Ugh, reminds me of the time I had to integrate with a bunch of school software. They used csv over ftp (no auth). You just had to connect to the server and get the personal information of a district's students. Worse is you could google the URLs... I built a system that solved the problem but left shortly after it began to be integrated nationwide.

Email me at josh.ribakoff at Gmail I'd be interested in chatting. I think we worked at the same company. Or direct competitors

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

#86
post #36

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.

Especially when FTP and HTTP performance is basically comparable and will depend more on the network and storage than the protocol.

Have we gotten to the point where anything not HTTP is considered old?

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

#87

I had an integrator request this so I stood up a nodeJS server that only implements upload, not download. This way if they leaked their own password, a malicious actor is limited to forging data, and no real data can be leaked. Because it didn't work in FileZilla, they didn't want to use it. Worked at another company that shuffled data between big name gyms & health insurance companies, it also used CSV files sent ov…

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.

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

#88
post #68
post #53

Earlier quoted context omitted.

You can do a lot worse than ACH. It's hard to read, but it's simple and pretty well-defined. What _really_ sucks is one-off fixed-width formats that aren't well defined, or that change suddenly (oh, you thought that field would always be populated? lol no.)

Yeah, ACH is surprisingly not-unpleasant, at least relative to nightmares like X12 EDI with its implicit looping constructs and billions of companion guides that supercede random parts of the base spec.

X12 EDI, been there earned the badge, both on the generating and receiving sides. 837, 834, 835 and others in health care - fun! Positional format, with situational meaning... really it is a fascinating format.

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

#90

I had an integrator request this so I stood up a nodeJS server that only implements upload, not download. This way if they leaked their own password, a malicious actor is limited to forging data, and no real data can be leaked. Because it didn't work in FileZilla, they didn't want to use it. Worked at another company that shuffled data between big name gyms & health insurance companies, it also used CSV files sent ov…

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.
Post reply on HN