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

How ACH works: A developer perspective – Part 2

engineering.zenpayroll.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: How ACH works: A developer perspective – Part 2

#11

Post by tomasien »

us0r wrote: post #9
edawerd wrote: post #5

Earlier quoted context omitted.

I'm curious, if you don't store usernames and passwords for banking credentials, how do know if the ACH transfer will NSF? Do you ask the account holder for their bank credentials each time you want to pull money from their account?

Basically scrape the account. Avg daily balance is probably the primary number. Low balance, high balance, NSFs, etc.

Pretty close! We're not scraping anything which I'll clarify more for the connotation that this is web scraping - it's not.

Re: How ACH works: A developer perspective – Part 2

#12

Post by pfg »

tomasien wrote: post #2

If you find this interesting you may find the work Knox is doing pretty cool - we're able to verify funds before we make payments (so there no NSFs), get and verify account numbers without asking for the user to tell us them, and verify the identity of the payor all in one step - we just have them log into their online banking (like you do with Mint or Yodlee except faster). We've never had an ACH file returned ever,…

There's a payment provider doing something similar called "Sofortüberweisung" (translates to "instant (bank) transfer"). It is pretty popular in Germany, AFAIK they only support banks from Germany (and maybe some neighbouring countries).

They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN.

Quite scary to be honest, to me at least. It's basically a scraper/bot that initiates the transfer for you, pretending to be you, without the bank's knowledge. While forwarding your login information and TANs to third parties is by most banks considered a violation of their ToS, they don't seem to be willing to do anything about it (probably because of Sofortüberweisung's popularity with their customers).

Re: How ACH works: A developer perspective – Part 2

#13

Post by napoleond »

tomasien wrote: post #4
richardwhiuk wrote: post #3

Earlier quoted context omitted.

You should fix the lack of SSL security on thesimpledifference.com Why? iFrame SSL certificates aren't visible, and no, your VeriSign trusted doesn't count. This means users will find it offputting as you note. Why else? Someone could hijack the HTTP page and point the iframe location somewhere else where they then intercept bank details. Next knox only seems to support a limited number of banks, unlike ACH which I'm…

Agreed on the SSL bit - we ask all our businesses to use it but we didn't put it on our test site. That's embarrassing I'm putting it up now. And yes, we serve the 30 banks that constitute 60% of banking volume in the US, and at least 60% of banking customers (although we suspect more, since many people who have a smaller account have a top 30 account too). We're increasing that number, but you can turn our system on…

I don't have a US bank account so this doesn't affect me, but just speaking as "Joe Consumer" you may want to address parent's point about the bank's T&C, since that was the only part of his comment that jumped out at me and the only part you didn't address.

Re: How ACH works: A developer perspective – Part 2

#14

Post by tomasien »

pfg wrote: post #12
tomasien wrote: post #2

If you find this interesting you may find the work Knox is doing pretty cool - we're able to verify funds before we make payments (so there no NSFs), get and verify account numbers without asking for the user to tell us them, and verify the identity of the payor all in one step - we just have them log into their online banking (like you do with Mint or Yodlee except faster). We've never had an ACH file returned ever,…

There's a payment provider doing something similar called "Sofortüberweisung" (translates to "instant (bank) transfer"). It is pretty popular in Germany, AFAIK they only support banks from Germany (and maybe some neighbouring countries). They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN. Quite scary to be honest, to me at le…

We initiate the transfer as well. It doesn't violate any of the banks we support's TOS. We're also not web scraping.

Re: How ACH works: A developer perspective – Part 2

#16

Post by pfg »

tomasien wrote: post #14
pfg wrote: post #12

Earlier quoted context omitted.

There's a payment provider doing something similar called "Sofortüberweisung" (translates to "instant (bank) transfer"). It is pretty popular in Germany, AFAIK they only support banks from Germany (and maybe some neighbouring countries). They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN. Quite scary to be honest, to me at le…

We initiate the transfer as well. It doesn't violate any of the banks we support's TOS. We're also not web scraping.

Sorry, edited my comment a bit to clarify.

If I understood correctly, you use the login to verify the account information and to check whether funds are available. The transfer is initiated via ACH.

Sofortüberweisung doesn't use ACH (or SEPA), they actually transfer the money via Online banking using a bot pretending to be the account owner.

Re: How ACH works: A developer perspective – Part 2

#17

Post by [deleted] »

tomasien wrote: post #14
pfg wrote: post #12

Earlier quoted context omitted.

There's a payment provider doing something similar called "Sofortüberweisung" (translates to "instant (bank) transfer"). It is pretty popular in Germany, AFAIK they only support banks from Germany (and maybe some neighbouring countries). They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN. Quite scary to be honest, to me at le…

We initiate the transfer as well. It doesn't violate any of the banks we support's TOS. We're also not web scraping.

[deleted]

Re: How ACH works: A developer perspective – Part 2

#18

Post by tomasien »

pfg wrote: post #16
tomasien wrote: post #14

Earlier quoted context omitted.

We initiate the transfer as well. It doesn't violate any of the banks we support's TOS. We're also not web scraping.

Sorry, edited my comment a bit to clarify. If I understood correctly, you use the login to verify the account information and to check whether funds are available. The transfer is initiated via ACH. Sofortüberweisung doesn't use ACH (or SEPA), they actually transfer the money via Online banking using a bot pretending to be the account owner.

OHHHH that's messed up. Wow! That's a really weird thing to do, but the fact that it's popular anyway really says a lot. Still though - wow.

Re: How ACH works: A developer perspective – Part 2

#19

Post by tomasien »

napoleond wrote: post #13
tomasien wrote: post #4

Earlier quoted context omitted.

Agreed on the SSL bit - we ask all our businesses to use it but we didn't put it on our test site. That's embarrassing I'm putting it up now. And yes, we serve the 30 banks that constitute 60% of banking volume in the US, and at least 60% of banking customers (although we suspect more, since many people who have a smaller account have a top 30 account too). We're increasing that number, but you can turn our system on…

I don't have a US bank account so this doesn't affect me, but just speaking as "Joe Consumer" you may want to address parent's point about the bank's T&C, since that was the only part of his comment that jumped out at me and the only part you didn't address.

It doesn't. Thank you for pointing that out. Mint did a lot of the work for us here to be honest, they made it really easy to get this stuff out of the way.

Re: How ACH works: A developer perspective – Part 2

#20

Post by hobs »

I have written exports from various payroll systems to produce NACHA compliant ACH files to upload to banks, every time there was a problem the bank would get back to us through the customer and we would get super weird or vague responses. In the future I am going to ask for the return codes ( https://zenpayroll.com/ach_return_codes) listed in the article, very useful bit of info, thanks!
Post reply on HN