http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/ User submitted comments to Practical Ecommerce's article entitled Accepting ACH Payments and eChecks en-us Copyright 2007 Confluence Publishing Sat, 09 Feb 2008 14:23:44 -0700 http://www.practicalecommerce.com/rss/ Practical Ecommerce v2.0.1 Ecommerce kmurdock@practicalecommerce.com bgetting@practicalecommerce.com 60 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment5443 Quoting this: "Mayes said eCheck.Net offers a customizable application program interface similar to the one used to process credit card payments, which means the programmer wouldn’t have to start from scratch. If you already use Authorize.Net for credit card payments, the programmer just needs to change a few things here and there to make eCheck.Net fit with your website." I am a software developer and i just need the integration sample code with eCheck in any popular platform like ASP.NET, PHP, VB etc. Could you tell where exactly should i go, i went through the documentation provided by Authorize.net and did not find such thing. Sat, 09 Feb 2008 14:23:44 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment5443 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment4715 I have already created Authorize.Net - AIM transaction method (in PHP) for my client. For this I have found the sample PHP code in the Authorize.Net website. Now my client needs to implement the eCheck.net. I didn't get any PHP code to implement echeck.net. I need to know, 1. whats the procedure to implement ACH (eCheck.net ) 2. From where I get the PHP Code for eCheck.net. Please help me out. Tue, 22 Jan 2008 04:13:09 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment4715 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment4645 Kevin, There are several reasons why you need a third party: 1. Online ACH transactions have to be coded as WEB (sec code) and there are rules for that. The main being that no one other than the owner of the bank account and the ACH operator, bank or third party ACH processor, are allowed to touch that transaction. You cannot take the information from the consumer on your website and then enter it in a bank software and process it. This is against NACHA rules for WEB transactions. 2. A third party operator might also help you with scrubbing of those transactions by using several verification systems that range from in-house private negative databases to verifications through Star ATM and other networks. As far as the cost, you are right, an ACH is relatively cheap when you look at the raw cost from the FED or NACHA, but actual pricing are nowhere near that since that raw cost is not considering the following: 1. Bank/processor liability. 2. Processing costs. 3.... Thu, 10 Jan 2008 09:00:43 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment4645 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment413 That makes sense, Kevin. I can see your point. Wed, 21 Feb 2007 14:16:08 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment413 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment412 I'm not sure I agree with you that that's the issue. Suppose I have my own web site with SSL and PHP, and I have my own system that can let a buyer enter their bank account. Why do I need a third party? ACH transactions cost $.0001 cents for the ODFI, so I imagine my bank should only charge me nominally more than this: http://www.nacha.org/News/news/pressreleases/2007/Pr020507/pr020507.htm So again, I can see why I need a 3rd party for Visa because Visa controls access to their service, but ACH is a network of thousands of banks with a ridiculously low per use cost. Wed, 21 Feb 2007 13:30:49 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment412 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment399 The issue, Kevin, is linking the ACH payments to your shopping cart, so that your online customers can choose this option in real-time during checkout. Thank you for the post. Tue, 20 Feb 2007 16:59:33 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment399 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment398 I don't understand something. Why do I need a third party at all for ACH? Why can't I just use my bank and my customer's bank? I understand why I need a third party for Visa, because there are only two companies- Visa and Mastercard - but since ACH is a huge network, why can't I just either join the network, or just ask my bank to initiate an ACH transaction on my behalf? Tue, 20 Feb 2007 16:27:54 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment398 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment215 Hi Beth! You are welcome, and I thank you for the kind words! I used to play in the online space for the Walt Disney Travel Company, and surprisingly enough, very few people know about online payment solutions! If anyone would like suggestions re this space, please feel free to ping me: jamynigri [@] gmail.com. All the best Jamy Sun, 28 Jan 2007 04:33:05 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment215 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment211 Thank you Jamy, for your insightful comments. That was equally or more useful than the original article! Sat, 27 Jan 2007 05:23:35 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment211 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment185 Disclaimer - I am the VP, iDistribution 2.0 for one of the global leaders in online payments. To make your best decision, please consider these factors as well, as ACH is not the only alternative payment type that is safe, secure and protected by sophisticated Fraud Protection Servers. 1) Fraud Protection - how sophisticated are their fraud servers? Do they move beyond the simple realm of address/billing information verification and are they able to flexibly adjust by merchant type, country, payment type, payment history and even time of day 2) Customer Support - do they have a multi language Call Center to provide real time customer support to finish the transaction and provide the highest levels of user satisfaction 3) Languages - does their call center offer multi language capability 4) Currencies - are multiple currencies accepted around the world enabling global commerce 5) ASP v. PSP Model - is there no fee for hardware/software upgrades installation as a result of... Sat, 20 Jan 2007 20:14:36 -0700 http://www.practicalecommerce.com/articles/173/Accepting-ACH-Payments-and-eChecks/#comment185