ACH Payment Integration

• API availability: Does the partner offer RESTful, SOAP  ACH transaction integration or both?
• What other payment utilities are available?
• If your market base includes Canada, does the partner provide a single API for both US ACH and Canadian EFT?
• Does the platform meet PCI Security standards even though NACHA does not require ACH transactions to be PCI compliant?
• Is sensitive data tokenized and can a call be made to immediately tokenize the bank account data prior to an origination?
• Are there opportunities to leverage the ACH Processing Integration for your apps’s revenue stream?
• Are there ancillary utilities available from the ACH API to make calls for anti-fraud and risk mitigation?
• Does the partner provide assistance in ACH payments processing adoption for you and your user clients? Simply offering a payment method is not enough to get end user adoption.
• Are there risk acceptance models available that could lower processing costs?
• Are there white label possibilities that might allow for a branded processing option, keeping the ACH processor behind the scene?
• Is there an API that would allow your customers to apply from your site or app?
• Will your potential partner take the time to understand your business requirements and provide options that custom fit the payments needs to your needs and your clients?
• How long has your potential integration partner been serving the needs of app providers and what is their track record?

That’s just a start at some of the common questions you might ask. With Agile Payments, we take the time to learn your business requirements and needs first. We have ACH app clients in sectors that span a wide spectrum. In every case we have become a valuable and trusted partner to these providers–to the point where we help in other business areas [eg client acquisition strategies].

Other reasons ACH integration of payments makes sense:

Paper checks simply don’t work for organizations or applications wishing to accept payments from bank accounts. Even if they did, paper checks are burdensome and expensive in handling. If an application provides payouts to affiliates or businesses for services or goods, it’s far less expensive to have an ACH Integration to handle what would be the ACH Credits.

Paper checks are also far more suspect to fraudulent use than anything facilitated via an ACH Integration. ACH Integrated payments eliminate the worry of fraudulent use if remitting payments by paper check.

Creating an ACH payment integration solution leads to more satisfied clients. It can provide a more economical method for streamlining cash flow, and if there are recurring payments requirements as part of your app or market you serve, we are the experts. Predictable, less expensive payment vehicle and API functionality that will empower your software and add value for your user base.

Disputed transactions are less likely with ACH transactions. Credit card transactions can be disputed and charged-back for a number of reasons. That’s not the case with ACH transactions. There are only three reasons that an ACH transaction can be disputed; The transaction was simply not authorized to be debited, the amount was incorrect or the date that it was processed in incorrect. In each of the three cases a formal affidavit must be completed at the bank where the ACH debit was drawn upon.

The recurring cycle of ACH payments just keep going and going. Earlier we discussed credit card expirations, stolen cards, re-issued cards (EMV) and the associated credit card declines. An application with recurring payments requirements that has completed an ACH integration realizes the great benefit of setting up a user for ACH recurring payments and not worrying about declines. They pretty much set it, and forget it as far as the recurring ACH is concerned. The only reasons to interject into a particular user’s account is for a return notification, typically non-sufficient funds. This is where a good ACH API can be valuable. First, understand that rejected ACH transactions have two re-presentment originations available to try to capture what was the NSF funds. Favorable re-presentments vary by business type, but the parameters available should be, Immediate, being delayed by a specified number of days, a smart date such as a logical pay date like the first or 15th of the month, or a specific day of the week, e.g., Friday. The SaaS organization can programmatically manage any NSF returns they get by leveraging retry field parameters via the ACH integration API. Further, the origination of a separate NSF fee transaction can be automated programmatically if the SaaS organization wishes to assess and capture one. That’s a decision that varies based on organizations, but re-trying NSF’s is not; it’s universally accepted.

ACH payments get preferred settlement. Checking and savings account settlements are not treated the same. While each bank may have some procedural differences, ACH transactions are generally the first to be settled and reconciled. For example, If Suzy Jones has a $500 balance in her account and an ACH debit transaction shows up on a Monday morning at the same time a paper check for Suzy’s account is presented, the ACH transaction is the one who gets paid first. Why? Well, you’d have to ask each bank but suffice it to say that if the ACH transaction is rejected for non-sufficient funds, the bank get’s nothing in the way of fees. If they reject the paper check, the bank can assess an NSF fee. Ever heard the term “follow the money”?