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

201–210 of 226 posts

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

#201

Post by TACIXAT »

>At Gusto, we rely heavily on the ACH network. For example, when a company runs payroll, we’ll use the ACH network to debit the company’s account to fund their employee’s pay. Once we’ve received these funds from the company, we’ll again use the ACH network to initiate credits into each of the employee’s accounts to pay them for their hard work.

Can you use ACH to initiate a transfer between two (third) parties (i.e. you not being one of them)? If not, what are the requirements to be a broker / escrow in between them?

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

#202

Post by ChemicalWarfare »

ryaniscool wrote: post #192

There are several companies that provide an API on top of ACH. I work for one[1]. For high volume ACH (like a payroll company) it's usually cheaper to go through an API provider than it is to go directly through the bank. I'm not exactly sure why. Maybe because we handle technical support? We also have better reporting. One of the challenges for banks is that there is an oligopoly on the software that runs the bank.…

From my experience it's extremely rare even for large companies to directly deal with ODFIs.

Typically there's AT LEAST one intermediary payment processor (like Chase Paymentech) involved in the TX.

The downside to this is merchant has to register with multiple processing entities but things like "send and forget" APIs (so no need to batch things manually) - which makes it easy to combine ACH and CC payment acceptance in the same system, reporting/reconciliation, out of the box UI merchant can use to look up transactions etc etc outweigh that inconvenience.

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

#204

Post by ihattendorf »

jdmichal wrote: post #200
joncrocks wrote: post #196

Earlier quoted context omitted.

The difference is, however, that you can assign a bank account a number that is unique within a given banking system. Once you move into the realm of trying to tie an identifier you have no control over (and that has no reliable verification method for) to a place where money will go, you open yourself up to a smorgasbord of potential attack vectors, confusions and edge cases.

Bank account numbers are not unique across banks. Account number schemes aren't even uniform across banks. The only limitation is what fits within the ACH system. You need the combination of routing number (to identify the bank) and account number (to identify the individual within the bank). Zelle associates the bank account to a email address and / or phone number. Creation of these associations is gated through th…

If all you need is a phone number to pay, how does it handle multiple accounts? Or can you only sign up for a single account?

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

#205

Post by wolfgang42 »

marktangotango wrote: post #168
dmlittle wrote: post #102

Earlier quoted context omitted.

Every time someone complains about file formats I bring up a similar story. It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor...

Ha! I wrote an editor for fixed length files, it lets you map to a cobol copybook, or create the layout manually. I never released it. Anyone interested?

If it works on Windows, I'd love to give it a try! Our ERP system is written in COBOL and I have to deal with fixed-width files all the time. Does it also handle REDEFINES and level 88?

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

#206

Post by jandrese »

lucaspiller wrote: post #145
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 most of Europe (UK and IE are one exception still using SWIFT) you just need the IBAN (international bank account number). In a lot of cases the payment is instant, even between countries, and free. Unlike the US the bank account number shouldn't be guarded with your life, so businesses often have it listed on their website.

US Bank account numbers aren't proprietary knowledge. They're written in plaintext on the bottom of every check.

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

#207

Post by kar1181 »

BoorishBears wrote: post #182
kar1181 wrote: post #169

Going from the UK to the US was like stepping back in time when it came to banking. I remember complaining about some aspects of UK banking - it's going to take a day for my transfer to complete!?! Now we have faster payments in the UK which complete in hours at most. Meanwhile in the US I still had to pay my rent with a physical check because that was easier than figuring out the weird 'pay anyone' implementation my…

Your property management doesn't provide a way to pay online?

Private landlord.

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

#208

Post by eric_h »

20after4 wrote: post #110
sixdimensional wrote: post #88

Earlier quoted context omitted.

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.

Don't you mean nightmare format?

Nightmares can be fascinating

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

#210

Post by DoubleCribble »

jandrese wrote: post #206
lucaspiller wrote: post #145

Earlier quoted context omitted.

In most of Europe (UK and IE are one exception still using SWIFT) you just need the IBAN (international bank account number). In a lot of cases the payment is instant, even between countries, and free. Unlike the US the bank account number shouldn't be guarded with your life, so businesses often have it listed on their website.

US Bank account numbers aren't proprietary knowledge. They're written in plaintext on the bottom of every check.

And that's a problem. Here's the discussion from last year.[0]

[0]https://news.ycombinator.com/item?id=11833009

Post reply on HN