While a successful ACH API integration largely depends on the business and their requirements itself, there are a few things that cross the requirement boundaries and apply to most all ACH integration needs.

The integration method

One size doesn’t fit all. There’s a plethora of API’s out there that will allow you to integrate an application for originating ACH transactions. It’s whether or not the API fulfills the requirements that your organization has. Finding the right API integration starts with discussions of the potential suitors. Ideally, the application’s staff that has been tasked with researching and evaluating ACH API possibilities has been provided with a list of requirements from the application’s stake holders or senior staff. At Agile Payments, we like to gather as much information as possible in order to have a productive conversation. We like to know:

• What type of business it is and what the business model is.
• Have a transaction flow chart showing what go where and from whom.
• What products or services are provided if debits are involved.
• Who is being funded if credits are involved.
• What the required and requested transaction limits will be.
• As well as any particular requirements determined by the organization.

Once we have a clear picture of all the requirements, we can usually pin-point to the appropriate integration method, assign a sandbox for that particular method and provide API credentials for integration development and testing.

Integration Support

Over our 18+ years in assisting organizations with ACH API integration, we still see unique requirements every week. If the integration hits a snag and can’t be solved, it’s man hours wasted – or a failure point that leaves the integration with a weak point. In most cases it’s simply a matter of getting the right technical support when an engineer has an issue. It’s paramount that the integration engineers have access to a live human for support that has knowledge of the API method being used. Simply providing API documentation for developers to sift through isn’t enough. Too many man hours can be wasted if resolving an integration issue were left to documentation alone. Moreover, a good integration support person has the ability to listen to not only direct API questions, but also the ability to listen to business requirements and present programatic solutions that will meet the organization’s requirements.

Owning the data

There are times where an integrated organization needs to migrate from one ACH integration to another processor. If the integrated application has a significant amount of customer data, it’s crucial that the data be made available by way of a secure transfer process. Data shouldn’t be held hostage from an integrated company. We see this far too often, and it’s something that is rarely considered when an application evaluates and chooses and ACH integration. Data hostaging doesn’t show it’s ugly head in one form only. It can be ridiculous fees required to migrate the data. We have personally witnessed a company who wanted to migrate away from their current processor to Agile Payments be presented with a work order in the amount of $50,000 in order to migrate the data. Now THAT is beyond robbery. Sure, there’s work involved to transfer data securely, but it shouldn’t be more than a few hundred dollars. Find out the data migration policy before you integrate.

Payment Channels

Think ahead. Maybe your application will only end up needing web based payments. Or, maybe not. What will the future hold for your application? In the future will it need point of sale, mobile, phone, IVR? Make sure the integration partner can support any anticipated channel needs.

Single Integration

Many businesses that seek an ACH integration also require credit card processing. If you’re already integrated for credit cards, this is somewhat less of an issue. If not, having an integration method that supports both the payment rails eliminates an integration. It also provides a single point of data return and billing.

Reporting is Crucial

Not having reporting data to present to the users of your application either leaves them in the dark or relying on the ACH processors web portal or ftp solution to acquire and present transaction reporting. In our eyes, that’s a failure point of an integration. Transactional reporting should be available via the API using webhooks or callbacks to automate the presentation of transaction reporting within your application, as it happens.

For applications that have a vertical base, you want to see transaction data from your application’s users. While sensitive data must be withheld, you still want to have a bird’s eye view of transaction volume and returns data. This is even more important if you are involved in a revenue share agreement with your processor.

On-boarding process

Some organizations require the boarding process to be presented and started within their application – a white label approach. While it might still be a contractual relationship with the processor itself, everything in the boarding and application process should be possible to embed in the organization’s application. This should be available via API. Additionally, there should be a choice of who receives the API credentials. Some applications require their users to input the API keys, while others are programmatically configured for API key entry to be done at the software application provider level. Make sure your requirement can be met.

Contact us to discuss your ACH integration needs. Myself or another C-level executive will reply to any contact form that has substantial initial information provided in the comment section.