Some applications are more favorably aligned with acceptance of eCheck (ACH) transactions than others. Applications that are proprietary and align themselves well with eCheck acceptance and only support their business can often start out with using an external transaction management tool for payment origination and management. On the other hand, applications that are used my multiple organizations or businesses are far less likely in being able to get by with utilizing an external payment management tool. Let's examine some key areas that factor in to whether and when an ACH Integration might make sense.
Vertical application or internal use only
Software applications that are built for the purpose of outside organizations and businesses using them to manage their operations in one way or another is a prime focus area for deciding to integrate to an ACH API. Moreover, if the types of businesses that use the application are favorably inclined to accept eCheck transactions, the decision to integrate is usually sooner, rather than later.
Businesses that are favorable towards eCheck acceptance will be looking for the application to already be integrated for eCheck acceptance. To not have an ACH integration would be lost opportunity costs. Stakeholders generally know whether the using organizations are favorable towards eCheck acceptance, but in some cases not so much.
Applications that are geared for something like church management or property management fully understand the need for capabilities within their platform. An application that is used for managing something like construction services might be less inclined to estimate the value of ACH integration and eCheck acceptance. For the latter type it's usually requests from using organizations and businesses that point them to the benefit they seek from it.
Software that is built to serve only a single organization is more solely dependent on whether their business model aligns itself favorably with eCheck acceptance - and transaction volume.
Transaction volume comes into play for both types of software applications, internally specific and vertical. However, integration to an ACH API for an internal, specifically built application, is far more likely to weigh transaction volume than one that supports a vertical user market.
Those organizations who use an internal application will weigh transaction volume against development time in justifying their decision to integrate. While an ACH integration can be accomplished in sort order in some cases, the depth at which the development team needs to integrate to meet their requirements for reporting, notifications, etc., can extend the development time.
For applications that serve a vertical base, transaction volume is a lesser factor, assuming the using organizations align themselves well with eCheck acceptance.
What's the magic number of monthly eCheck transactions for an internal application team to decide to integrate? There isn't one. While no internal application would integrate having an eCheck monthly transaction volume of 100, the benefits are organization specific, and each will arrive at their own magic number. And of course there's another factor that comes into play - cost savings.
Costs savings from the eCheck payment rail
For businesses and organizations that are well aligned to eCheck acceptance, it's no secret to them that a great deal of what they would be spending on credit card processing fees can be saved by utilizing the ACH payment rail. The higher the average transaction amount for a given organization can return the greatest savings by utilizing eChecks.
In closing, the decision to integrate to an ACH API weighs on all three of the above factors. Each organization's use case is different, and the best way to get a handle on what might be the best way to tackle an ACH integration is best found by consulting with those that have been supplying API integrations to organizations and businesses of all sizes for a long period of time.
Is your organization ready for an ACH API Sandbox? Get started now...