For applications having a recurring or subscription payments component, an ACH API is a must have for payments integration.
Ideally, the ACH API will also have a credit card payment rail component, providing a single source gateway for both payment methods.
Application stakeholders and senior employees should discuss and layout their anticipated payments requirements before contacting ACH API potential vendors. A good ACH provider will want to know everything possible about the application, its user base, the transactional flow and reporting requirements. This is critical for provisioning the proper ACH account, as well as identifying and providing the appropriate ACH API integration method and establishing the proper technical support contacts for the integrating client.
What are some reasons to integrate to an ACH API?
Provides an additional payment rail: Not everyone has a credit card. And for customers that do have a credit card, providing ACH as an additional method for remitting payment can provide a fall-back method in the case of a stolen, expired or re-issued credit card. Bottom-line; two methods for payment remittance can save loads of time spent by employees chasing down declined transactions.
Provides a less expensive processing avenue: It’s no secret that ACH transactions are much less expensive than credit card processing. That said, ACH transactions lend themselves well to some organization types, while other types might not benefit as well. Those companies and organization who do benefit from ACH processing tend to know their customers well, i.e., they are of a recurring nature. Businesses who sell a product to a one-time customer on the internet are less likely to benefit from integrating to an ACH API. The bottom-line is that ACH Processing fees can be 80-90% less expensive than credit card transaction fees. Assuming a large recurring customer base, the fees saved via ACH processing can be significant.
Revenue Share: While merchant organizations differ in their business models, understand that most all organizations have leverage that can be used to generate revenue from the ACH transactions. It’s your organization that integrates and, in essence, becomes a sales agent for the processor. There is a cost of sales and marketing, so why should your organization pass on the leverage opportunity at hand? Discuss your application with your potential ACH vendor so that they have a clear understanding of the application’s transaction potential. This will lead to a win/win revenue share agreement that both provides your using organizations with a better than market rate, and yet still adds revenue to your bottom-line.
Credit card decline rates are high: Recurring credit card decline rates are around 15%, and sometimes exceeding 20%. ACH payment processing return rates are far lower – less than 3% for a subscription based merchant. That means that an additional 15% of revenue is funded without having to hunt-down customers who had a transaction declined because of an expired or re-issued credit card. Checking and savings accounts don’t have expiration dates and are not nearly as susceptible to being closed or re-generated due to data theft. This makes an ACH API integration a perfect choice for any SaaS that has a subscription payments component.
ACH Integration Methods for SaaS providers
Assuming a SaaS organization and its stakeholders have examined and concluded it’s beneficial to add ACH as a payment vehicle to their platform, as discussed in our video ACH as a SaaS Benefit, now comes the time to discuss how.
Multiple integrations methods are available for integrating ACH as a payment vehicle, including maintaining their existing credit card merchant account and passing card transaction data via a single gateway, reporting back both credit card and ACH data via a single API integration. There are also methods that can allow the SaaS platform to reduce their PCI scope by way of removing the need to touch and store sensitive data on their web servers. While ACH transactions don’t fall under PCI scope, best practice is to treat all sensitive data as though it does.
Provide as much information as possible when discussing with the ACH integration partner. Providing a thorough use case can reveal suggestions from your ACH partner that can assist you not only in your integration, but also help mold a more successful adoption rate, and perhaps a better bottom line fiscal result. In some cases, the integration choices can result in an ACH SDK that is tailored specifically to the development stack the SaaS platform is using, as well as the specific ACH API calls that will be required to meet the SaaS transactional requirements, eliminating the sifting through unrelated strings of API data that won’t be called upon.
If you’re SaaS has decided it’s time for ACH integration, call the experts who have been assisting applications and their stakeholders for over 17 years, Agile Payments.
- API availability: What ACH API tools does your prospective vendor make available?
- Does yoour 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?
- How is data stored? Does your prospective ACH partner tokenize the sensitive data?
- Are there opportunities to leverage ACH transactions for your SaaS revenue stream?
- What about KYC (know your customer)? Can calls be made for anti-fraud and risk mitigation?
- Does the partner provide assistance in ACH payments processing adoption for you and your user clients? In other words, will your vendor become a true partner towards the success of your customer base adoption of ACH?
- What’s the boarding and underwriting process like? Are there white label options? Providing a branded boarding process via API that is presented within your website or application can streamline the boarding process.
- How well does your prospective ACH vendor understand your business? Have they taken the time to understand all the requirements that will make the integration a success?
- How long has your potential integration partner been serving the ACH needs of SaaS applications, and what is their track record?
Other reasons implementing an ACH API makes sense:
Snail-mail paper checks just don’t cut it! They are burdensome and expensive to process and handle. Paper checks are also more likely to be fraudulently used than ACH transactions.
Implementing an ACH API can lead to more satisfied customers. At the same time, it creates a more streamlined cash flow.
Transactions that are charged-back 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 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.
The recurring nature of ACH transactions keep happening. Bank accounts don’t expire. With credit cards, not only do they expire, there’s also compromised cards and stolen cards that lead to a re-issue.
An application with recurring payments requirements that has completed an ACH API integration realizes multiple benefits of setting up a user for ACH recurring payments. 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. ACH transactions that have been returned for non-sufficient funds have two re-presentment originations available to attempt in capturing what was the NSF transaction. The merchant can programmatically manage any NSF returns they get by leveraging retry field parameters via the ACH API.
ACH payments get preferred settlement. While banks differ slightly in their procedures, ACH transactions are generally the first to be settled and reconciled. So basically, ACH transactions are settled in the morning, before any presented paper checks are settled.
An ACH Payment SDK or Software Development Kit allows a Software as a Service provider to integrate and automate payment collection or disbursement via the ACH network. The ACH SDK you work with should allow for all contemporary development languages, including Ruby, .NET, JAVA and PHP. Integration options typically can be accomplished via SOAP or using RESTful architecture.
Look for the following in an ACH SDK:
· Push notifications for reconciliation. Payment rejects handling and notification is an important consideration. Your app should not have to continually query for info
· Multiple payment modalities: One integration should handle ACH and credit cards
· US and Canada processing capabilities
· Developer support and end user support: Guidance with development and client service for your end users is critical
If you have questions regarding and ACH SDK, Contact Us.
Agile Payments has been providing ACH API solutions to software applications for 18+ years. We’re here to take the time to listen to your organization’s requirements and present the best solution options possible for your organization’s needs. Contact us to discuss your requirements.