This allows for automation of ACH payment collection, disbursement and reconciliation.

For applications having a recurring or subscription payments component, an ACH Payment Gateway API is a must have option for platform users.

• Benefits of an ACH API Integration as well as an overview of how ACH and credit card processing differ

• ACH Integration options including REST ACH API, SOAP ACH API as well batch processing

• What to look for in  ACH API Provider

• Area of potential concerns including risk mitigation and reconciliation options/challenges

• Case study of a successful ACH Transfer API Integration and the impact on customer acquisition and revenue generation

• Sample ACH API Code

• Sandbox ACH API accounts

• Additional ACH API Resources

Why integrate to an ACH Payments API and how will it benefit your application and business?

First you might be wondering how the ACH world works especially if you have some familiarity with credit cards.

ACH transactions operate differently than credit cards. Credit cards have an authorization component that lets the biller know in real time that the payment is good. The ACH and EFT processing world operates in a batch environment and it can be 24-72 hours before an issue with payment is known. This makes an ACH option very attractive to billers who “know” their customers eg a newspaper billing a  monthly subscription but. A business that needs to ship immediately after time of sale may prefer credit cards as the payment vehicle to mitigate payment issues.

There is also a major difference in costs. Credit cards may cost a business 2-3% of the transaction amount whereby an ACH is typically a flat 25-50 cent fee. This can add up. Coupled with much higher decline rates with credit cards ACH payments are a great option for recurring billing.

 

 

An ACH Processing 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.

ACH API CASE STUDY

ACH Payments also provide 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.

ACH payments have much lower decline rates than credit cards: 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.

Ideally, the ACH API will also have a credit card payment rail component, providing a single source gateway for both payment methods.

ACH Integration options for SaaS providers

You may choose from multiple integration methods including:

• • REST ACH API
  • SOAP ACH API
  • Batch ACH Processing via SFTP

The RESTful architecture is more modern and offers enhancements compared to SOAP and batch.A distinct advantage of a RESTful web service is in its flexibility. Data is not directly tied to methods, thus can accept and return many types of data formats. A RESTful web service is not constrained to XML as it can return multiple formats, which is ideal for a varying client base of integrated partners like a payment gateway commonly supports. Additionally, an ACH REST API, unlike SOAP, can communicate via a far simpler method, over HTTP. 

 

The best ACH API is one that strategically meets the vast majority of your needs. It’s extremely important to provide as much information as possible when discussing with the ACH API Payment Gateway 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. Questions you want answered:

• API availability: What ACH API tools does your prospective vendor make available?
• Does your ACH API provider offer both US ACH API 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 API partner tokenize the ACH 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?
• Is there an application API than can allow your users to apply for an ACH merchant account on your site AND have processing credential pushed to your app thereby eliminating frustrating credential entering for app users?
• How long has your potential integration partner been serving the ACH needs of SaaS applications, and what is their track record?Are there programmatic options to retry NSF (non-sufficient) ACH rejects

What should you be aware of before you start an ACH API Integration? 

Reconciliation and reporting

First is to make sure you understand the non real-time authentication that a payment debit will be successful. The payment reject rate for recurring ACH Payments tends to be sub 2% so the payment reject rate is no way near as problematic as credit cards but you will need to make a decision on reconciliation.

The decision about how your application will reconcile payment exceptions must be addressed early. You have 2 options:

1-Post or reconcile all ACH payments upon sending for processing. Essentially you are assuming all payments will be good. Your application user can receive notification or use some type of ACH Virtual Terminal to pull reports on NSF’s etc. They would them manually back out the payment and contact the customer.

2-Use the ACP Processing API and pull back reports on payment rejects as they happen [using REST] or on a daily basis. This would allow your platform users to know about payment exceptions within your SaaS.

Data can be delivered as soon as the gateway receives it from the RDFI banks instead of waiting for a cron delivered file. Because the SaaS application is integrated via the recurring payments API, this data can be automatically posted and reconciled. In addition, notifications can be triggered depending on the type of notification delivered.

For example, a settled ACH transaction post can trigger a message to customers or internal personnel of the event. Non sufficient funds messages delivered to the application can trigger a series of NSF re-presentment tries and, subsequent to a successful recovery, can trigger an NSF fee debit transaction to be originated.

Any organization that utilizes a software application and has a need for transmitting ACH transactions should further investigate ACH Integration and the advantages of integrating to a Recurring ACH API.

One significant thing to look for is the ability to tie ACH transactions to what has been funded in your bank account. Check out our blog post on ACH Deposit Reconciliation.

Other reasons implementing an ACH Payment 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 Processing 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 two reasons that an ACH transaction can be disputed:

• The transaction was simply not authorized to be debited
• The customer disputes something about the transaction, eg service was not provided

The recurring nature of ACH transactions keep happening. Bank accounts don’t expire. With credit cards, not only do they expire, there are 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

Agile Payments has been providing ACH Processing 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.

If you have questions regarding our ACH SDK, CONTACT US.

Case Study:

After comprehensive discussions a partner operating in the water treatment software space  leverage our ACH API to automate recurring monthly and quarterly payments for its large user base providing water treatment systems. They were also able to leverage credit and debit card solutions from the same processing solution.

Upon integrating, testing and launching the solution and combined with an outreach plan to target their application users they found 80%+ adoption rate of the payment solution.

Their software solution and the payments component is an integral part of their success. Their end users count on an value automated payment collection and reconciliation. Client retention rates are in excess of 95%. When you count on a SaaS to deliver your revenue it becomes very painful to think about leaving that application.

In addition they receive a revenue share from payments that not only defrays development costs but has created a more valuable business. SaaS platforms tend to be valued by RMR [recurring monthly revenue]. By adding a payment revenue stream their business is valued at a higher multiple.

In this partnership we worked together to roll out the payment integration and best practices for maximum end user adoption of AutoPay options. Our partner ensures the integration pathway is up to date and when enhancements are made eg credit card updater program, that the benefits are communicated to platform users. All payment support is handled on our end to minimize platform direct involvement.

ACH API Integration Code Samples

REST ACH API — Getting Started

To begin using ACH REST API  web services, complete the following steps:

1. Sign up for a Test Account.
2. Create your API Credentials.
3. Create your Authentication Headers.
4. Craft a call.
5. Test your calls.

Step 1: Sign Up for a Test Account

After registering and verifying your mobile number, you will login with your Organization ID. Your Organization ID represents a legal entity that can own multiple sub-organizations (for partners) or multiple locations (for merchants and some partners) as well as the customers, payment methods, and transactions that belong to those locations. Every request call made to the REST API must contain theorganization_id within the URI. Every sandbox account also comes with a Location ID. Locations are processing endpoints that merchant organizations use to initiate transactions. Locations own all the transaction data including sensitive payment method data and tokens.

Step 2: Create Your API Credentials

To begin integration with our ACH REST API, you first have to create your API authentication credentials. These include an API Access ID, which acts as your username, and an API Secure Key, which acts as a password. You will create and maintain these credentials from within your Sandbox control panel.

Complete the following steps to generate your API Access ID and API Secure Key:

1. From your Google Chrome browser, log into your Sandbox Account control panel.
2. Select Developer > API Credentials from the Main Menu.
3. Click the CREATE button. The Create API Credentials screen displays.
4. Enter a name for this set of API credentials in the Name field. This field is not required.
5. Use the dropdown menu in the Groups and Roles field to select All or a group that was predefined by your Organization Admin. Organization Admins use groups to give sandbox users access to specific organizations and their child locations. The default group for Organizations isAll.
6. Click the CREATE NEW API KEY button. The API Access ID and API Secure Key values display in their corresponding fields.
7. Click the COPY button next to the API Access ID and API Secure Key fields to record both of these newly generated values in a secure location to use in authenticating your REST API requests.

Once you save your API Secure Key, you will not be able to see the value again. 

Step 3: Create Your Authentication Headers

Requests to to ACH Transfer API must be authenticated using the Authorization header field and the custom header property, X-Auth-Organization-Id.

The Authorization Header

The REST web services rely on Basic access authentication over HTTPS using the API Access ID and anAPI Secure Key as the username and password values. These unique values are combined with a colon and then encoded using the RFC2045-MIME variant of Base64. The encoded string is then added to the HTTP Authorization header. For example, if you created the following API credentials:

• API Access ID = 315c7649520edde96c5cbad59a5b265f
• API Secure Key = c233f2958bd855d09d98397e74950640

The value of the Authorization header field would look like the following:

Authorization=Basic MzE1Yzc2NDk1MjBlZGRlOTZjNWNiYWQ1OWE1YjI2NWY6YzIzM2YyOTU4YmQ4NTVkMDlkOTgzOTdlNzQ5NTA2NDA=

Several different online tools can help you create your `Authorization` header, such as Postman. You can also add Base64 encoding to HMAC requests to automatically convert the API Access ID and API Secure Key values into the encoded ASCII string. To do so, use the following code:

Convert.ToBase64String(Encoding.Default.GetBytes(APIAccessID + “:” + APISecureKey)).Trim()

Step 4: Craft a Call

The following sections detail everything you’ll need to create a request call. The API Reference section lists and explains all the resources you can use and provides samples of common requests and responses.

Base URI

When constructing a call, append the resource endpoint to the following base URIs in the specified environments:

For example, to find a specific customer in Sandbox, you would append the customer endpoint /organizations/{organization_id}/locations/{location_id}/customers/{customer_token}  and perform a GET call. The complete URI,https://sandbox.net/api/v3/organizations/{organization_id}/locations/{location_id}/customers/{customer_token} will return all the customer data attached to that customer’s token.

Step 5: Test Calls

Using your sandbox send calls and verify connectivity/reporting

SOAP ACH API and Raw HTTP Web Service

The RAW HTTP POST protocol is intended for

•   non-Windows™ merchants
•   merchants unable to perform SSL operations
•   merchants with access to HTTPS routines

All transactions are routed through the web server in the following sequence of steps:

Step Description

1. Concatenate message into an ampersand delimited string.
2. Set the message to be passed as the “content” resource.
3. Perform the POST (URL provided to approved merchants).
4. Web server returns newline delimited response message (not HTML).

NOTE: This method sends the POST messages from the merchant’s server and not from the customer’s browser.

The SOAP web service supports two Operations:

•   ExecuteSocketDelimitedQuery: Accepts “strParameters” and “strDelimiter” parameters
•   ExecuteSocketQuery: Accepts Name Value Pairs

 Batch File Processing and Understanding the Process

The steps involved in uploading and downloading files are simple, but frequently cause confusion among users. The following is a high-level overview. Step-by-step, detailed instructions follow and explain each aspect of this process.

1. Upload the file to the system using the PUT command. Upload to the ul (“upload”) directory and use a file extension that begins with the letter “U,” followed by a two-digit batch number for the file name. For example, file CZ30011.U01.
2. Rename the file (using the RENAME command) to signal to the PG platform that the file is ready for processing. The file should remain in the ul directory. The file name can remain the same except that you must change the first letter of the file extension. Instead of a letter “u” for “upload” use a letter “r” for “ready.” For example, file CZ30011.r01 would be ready for processing (indicated by the “r” appearing immediately after the decimal). If the file name were CZ30011.u01, the file would not be ready; it would just have been uploaded.
3. The platform “picks up” the file for processing and the file will appear to be removed from the ulfolder.
4. During the processing cycle, the platform places batch confirmation and response files in the dl(“download”) directory.