Transaction origination, management and reporting tools and methods to an ACH Payment Gateway.
The first decision your organization will likely conclude on is whether you will require an API integration method or whether you
can rely on pre-built software tools. Generally speaking, the larger the organization, the greater the likelihood that an API integration will be required. The caveat there is that startup software applications are small at the beginning, but because they are being built to service other companies and organizations in managing their user base, most all of them will require an integration method. It’s the API integration method that will allow the ACH transaction origination, management and reporting to live within the application serving the organizations (or their customer base) who have a requirement for using the ACH payment rail.
Applications that serve a single organization or business can still integrate to an API for ACH payment gateway functionality, but ACH volume generally steers the path here. This is in part to the organizational capabilities in its information technology staff. Smaller organizations that are without sufficient IT staff would have to rely of outsourced development. Moreover, there will come a time when something, in one way or another, will have to be modified or supported on the development side. The smaller organizations should consult professionals who have dealt with ACH integrations to uncover potential shortcomings. If an integration to an ACH payment gateway is deemed less likely for an organization, this is where a pre-built software tool should come in handy.
Pre-built tools come in a few different varieties. The one that is the most well known is typically referred to as a Virtual Terminal. A virtual terminal is a cloud based application that allows an organization to originate and manage their ACH transactions and also supplies reporting data. In essence, it’s a software application that is in itself integrated with an ACH payment gateway. Virtual Terminals can be supplied by third parties who do not actually provide the ACH processing merchant account, e.g., payment gateway providers, or, the ACH provider of the merchant account might have their own virtual terminal application in-house. Virtual terminals supplied by a payment gateway provider will most always require a per transaction gateway fee. Virtual terminals provided by the actual ACH network processing provider will likely not require and additional per transaction gateway fee. Because ACH transactions are generally priced on a flat rate and are used to reduce processing costs, an additional gateway fee can be problematic – but not always. Using a payment gateway provider who has multiple third party ACH processing integrations can be helpful in situations where financial institutions may deem the organization’s industry sector as having a higher risk profile than they wish to accept. It’s best to consult with an ACH professional that has been serving the industry for long time and understands merchant risk profiles.
Other pre-built or semi-built utilities would include such things as utilities that are made to accept ACH payments via a website. They can be as simple as copying a snippet of HTML and pasting it within a web page, to advanced versions that allow a simpler integration method that calls data from a database in order to populate customer data within the payment utility. Some will provide a redirect to an externally hosted payments page and some will use something like javascript modal architecture that presents a payment modal on top of a client’s web page, transmitting directly to the ACH payment gateway.
