Many of my associations (customers) would like to be able to collect their own dues and fees online. Up till now, I have been recommending they deal directly with their banks to set up online payments (I would link to that page from my website) - but a lot of smaller banks don't have this capability.

I currently use Stripe for my own online credit card invoices and that would work great for them - except that it doesn't yet support ACH payments and transfers.

Do you have any suggestions or experience with this kind of situation? I'm looking for a low-cost service with a workable API.

TIA

We offer ACH service in two of our vertical market applications.

Before I explain how it is done, note that since we did this authorize.net has started offering eCheck.net. To use it, the merchant must have an authorize.net account and then further apply for echeck approval (there are additional underwriting requirements). Their eCheck.net is in essence a limited ACH API. There are also companies that will manage large numbers of ACH on your behalf, such as a school processing hundreds or thousands of ACH payments a month.

The problem with ACH is it is completely dissimilar to credit card processing, despite what it appears to the customer. There is no such thing as an ACH "approval" for a transaction, nor any way to know whether a transaction will be successful in the end (you will see why I say the end in a minute). ACH is considered a category of EFT (electronic funds transfer), and it simply the federal clearing house for checks deposited in banks in the U.S. It is the same -- literally -- computer system that clears all checks each night for the entire country and thus allows the banks to say the funds have "cleared", which means the fed has confirmed the transaction and credited the bank with the funds. FYI, the fed clears about 98% of checks the night after they are deposited -- bank "waiting times" for a check to clear are partially a gimmick. But I digress.

When banks started offering ACH transactions to their business customers, it allowed things like a student paying tuition in 10 installments via his or her checking account. Later it morphed into also allowing online payment the same way, although riskier.

So to the customer ACH looks like a cc transaction. But what really happens is as follows: the business' bank gives permission for the business to accept ACH payments. This is critical - the ONLY way to accept ACH payments is through a bank. There is no other way, and it has to be a bank where the business has account(s).

Then the merchant/business submits to the bank a text file of the ACH transactions. This text file has a very specific format, called the NACHA format after the organization that controls this stuff. That text file is literally uploaded by the bank onto the bank's computer system as a file of checks; it looks to the computer like somebody came in and deposited these checks. That night the computer contacts the fed and sends the info. We have a FP routine that creates this file. It is usually just emailed to the bank. It is in essence a low tech batch operation where a file is loaded onto a mainframe.

When the merchant's bank receives the file, it credits the merchant's account with the total of the transactions. Over the following days, any transactions that turn out to not go through, say for lack of funds or improper account numbers, get debited as they occur back from the merchant's account. There is no electronic way of managing this data. A helpful bank will send an email, then it is up to the merchant to adjust their records. Sometimes banks will give their merchants a program to enter the batch records, but it is just a formatter to get the NACHA format.

All this is why online payment processors generally do not deal in ACH, with the exception of the very large authorize.net. It is very risky, low tech, and labor intensive.

So you have two choices. Authorize.net, if the merchant can get approved and wishes to pay the fees, or the standard method via the merchant's bank. There is no way to just offer an ACH option in software like a credit card option; all ACH is done bank to bank.

Many of my associations (customers) would like to be able to collect their own dues and fees online. Up till now, I have been recommending they deal directly with their banks to set up online payments (I would link to that page from my website) - but a lot of smaller banks don't have this capability.

I currently use Stripe for my own online credit card invoices and that would work great for them - except that it doesn't yet support ACH payments and transfers.

Do you have any suggestions or experience with this kind of situation? I'm looking for a low-cost service with a workable API.

TIA

We offer ACH service in two of our vertical market applications.

Before I explain how it is done, note that since we did this authorize.net has started offering eCheck.net. To use it, the merchant must have an authorize.net account and then further apply for echeck approval (there are additional underwriting requirements). Their eCheck.net is in essence a limited ACH API. There are also companies that will manage large numbers of ACH on your behalf, such as a school processing hundreds or thousands of ACH payments a month.

The problem with ACH is it is completely dissimilar to credit card processing, despite what it appears to the customer. There is no such thing as an ACH "approval" for a transaction, nor any way to know whether a transaction will be successful in the end (you will see why I say the end in a minute). ACH is considered a category of EFT (electronic funds transfer), and it simply the federal clearing house for checks deposited in banks in the U.S. It is the same -- literally -- computer system that clears all checks each night for the entire country and thus allows the banks to say the funds have "cleared", which means the fed has confirmed the transaction and credited the bank with the funds. FYI, the fed clears about 98% of checks the night after they are deposited -- bank "waiting times" for a check to clear are partially a gimmick. But I digress.

When banks started offering ACH transactions to their business customers, it allowed things like a student paying tuition in 10 installments via his or her checking account. Later it morphed into also allowing online payment the same way, although riskier.

So to the customer ACH looks like a cc transaction. But what really happens is as follows: the business' bank gives permission for the business to accept ACH payments. This is critical - the ONLY way to accept ACH payments is through a bank. There is no other way, and it has to be a bank where the business has account(s).

Then the merchant/business submits to the bank a text file of the ACH transactions. This text file has a very specific format, called the NACHA format after the organization that controls this stuff. That text file is literally uploaded by the bank onto the bank's computer system as a file of checks; it looks to the computer like somebody came in and deposited these checks. That night the computer contacts the fed and sends the info. We have a FP routine that creates this file. It is usually just emailed to the bank. It is in essence a low tech batch operation where a file is loaded onto a mainframe.

When the merchant's bank receives the file, it credits the merchant's account with the total of the transactions. Over the following days, any transactions that turn out to not go through, say for lack of funds or improper account numbers, get debited as they occur back from the merchant's account. There is no electronic way of managing this data. A helpful bank will send an email, then it is up to the merchant to adjust their records. Sometimes banks will give their merchants a program to enter the batch records, but it is just a formatter to get the NACHA format.

All this is why online payment processors generally do not deal in ACH, with the exception of the very large authorize.net. It is very risky, low tech, and labor intensive.

So you have two choices. Authorize.net, if the merchant can get approved and wishes to pay the fees, or the standard method via the merchant's bank. There is no way to just offer an ACH option in software like a credit card option; all ACH is done bank to bank.