Why ACH Integration?
SaaS developers and platforms can automate payment collection, disbursement and reconciliation through the use of an ACH API (Application Programming Interface). This ACH option allows debiting and crediting of checking and savings accounts via the ACH network.
ACH Payment Integration allows a SaaS companies’ users payment options and benefits. Businesses that utilize a recurring payment model NEED an ACH transaction integration for multiple reasons:
- Banking 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, making ACH integration of payments an ideal choice for recurring payments based applications.
- ACH payments are widely accepted for payment facilitation by both consumers and businesses.
- ACH Processing fees are typically 80-90% less expensive than credit card fees.
- Credit card decline rates are on the rise. Average recurring credit card billing return rates are around 15%, while ACH payment processing return rates are typically sub 2%.
What Should a Business Look For in an ACH Integration API?
- Can you leverage the ACH Processing Integration for your apps’ revenue stream?
- Is there an API that would allow your customers to apply from your site or app?
- Other payment utilities available?
- Does the platform meet PCI Security standards (though NACHA does not require ACH transactions to be PCI compliant)?
- Does the partner provide assistance in ACH payments processing adoption for you and your user clients?
- Does the ACH API offer additional utilities to make calls for anti-fraud and risk mitigation?
- For market bases that include Canada: does the partner provide a single API for both United States ACH and Canadian EFT?
- Is sensitive data tokenized?
- API availability: Does the partner offer RESTful or SOAP ACH transaction integration, or both?
- How long has your potential integration partner been serving the needs of app providers and what is their track record?
- Are there white label possibilities that might allow for a branded processing option, keeping the ACH processor behind the scene?
- Can risk acceptance models lower processing costs?
- 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?
- Advanced ACH reconciliation capabilities that enables matching payment bank deposits to platform reporting.
Why Else Should One Consider ACH Integration?
Paper checks are a burden, expensive to handle, and simply don’t work for organizations or applications wishing to accept payments from bank accounts. Paper checks are also susceptible to fraudulence than anything facilitated via an ACH Integration.
An ACH Payment Integration solution is a predictable, less expensive payment vehicle, and API functionality will empower your software and add value for your user base. This will inevitably lead to more satisfied clients.
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 not authorized to be debited.
- The amount was incorrect
- The date that it was processed was incorrect.
ACH Integration and Payment Aggregation
An ACH Payment Aggregator or Facilitator can be thought of as being a Master Merchant who facilitates ACH transactions for sub-merchants within their payment ecosystem. Becoming an ACH aggregator or Payment Service Provider lends itself quite well to some businesses that fall into the software provider classification. Especially those who have recurring payments requirements via ACH integration.
The aggregation model was initially prohibited by credit card associations as well as the third party ACH processors. As PayPal grew rapidly it became clear that there was a lot of money to be made with aggregation. It became a model that the card associations had to embrace. While it’s still not widely provided by ACH processors, some have come to embrace the ACH aggregation model because of technological advances in KYC, advanced on-boarding processes and a better overall understanding of associated risks and mitigation processes to manage them.
The customer on-boarding process is a pivotal component for most organizations. To simply have an ACH Payment Integration option may not be enough. Many organizations prefer for the on-boarding process to be a “white label” process, meaning the third party ACH processor will remain in the background. The ACH integration must provide a way for the organization to pass their merchant’s data to the ACH processor’s underwriting department that requires it. This “passing” ideally occurs with everything in electronic format, including signatures.
The API must provide the ability for the application and underwriting process to be presented on their website, as though the ACH payments solution is coming from them. The underwriting data must be passed to the processor, the parties involved must be notified to where the application stands, and the API credentials must be passed to the applicant user once the merchant application has been approved and enrolled.
In some cases the credentials are passed to the merchant themselves. In the case a SaaS application the merchant user is required to enter API credentials themselves, and in other cases the API credentials are passed to the SaaS organization for entry on behalf of the merchant, depending on the ACH integration path that the SaaS organization chose.
Data hostaging is the inability for a merchant to receive non-tokenized card data in the event that they wish to switch merchant accounts, a situation that is becoming common in the credit card world. In some cases it’s simply prohibited by the processor, while in other cases a merchant must pay exorbitant fees in order to obtain the data. The process can be a long and arduous process, as processors try to delay the data transfer in order to maximize profits.
While ACH transactions do not fall under the same PCI scope as credit card transactions, most ACH processors who value sensitive data (and the potential theft of it) do tokenize ACH data in the same manner that credit card processors do.
A SaaS application can become the processor’s defacto sales organization for a payment processor. Many times this is predicated on whether the SaaS organization views the ACH integration as a payments partnership or wait to consider payment integration until near the end then choose a quick integration and be done with it (a mindset that is unfortunately all too common with developers). A payments partnership is a complex agreement, but the basics are that the SaaS organization and it’s using clients find an agreement among the rates, and that the processor can still find profit. Revenue share percentages can vary widely based on the reach and user base of the SaaS organization, but do your best at leveraging your application and it’s base in order to realize profit for yourself. After all, in a payments partnership, it’s your organization that is creating the leads for the processor.
