We’ll get back to you just a quick as we can.
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.
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 Canadian 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 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:
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:
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.
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 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:
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.
To begin using ACH REST API web services, complete the following steps:
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:
Once you save your API Secure Key, you will not be able to see the value again.
Requests to to ACH Transfer API must be authenticated using the Authorization header field and the custom header property, X-Auth-Organization-Id.
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:
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()
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.
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.
Using your sandbox send calls and verify connectivity/reporting
The RAW HTTP POST protocol is intended for
All transactions are routed through the web server in the following sequence of steps: Step Description
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:
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.
