Warren Buffet likes to invest in companies with a competitive moat. That is, their product, service or brand name presents competitors with significant barriers/problems in order to compete.
Software developers are constantly under pressure- Pressure from competitors in their market space, from customers with “special needs” and from their own company to produce the next “best” version of their product.
By integrating a payment processing solution that will offer end users the ability to debit (or credit) checking, savings or credit card accounts AND provide methods to automatically post and reconcile payments your company can build its own moat. Consider the alarm monitoring company who is choosing from four vendors to manage their 5000 clients. Your company is the only one that offers the ability to collect payments from these customers and post payments automatically. Who will they choose? Imagine you are competing against the company that can do those things. Clearly you can distinguish your company from those in your market space. Developers constantly are looking for upgrades to make their product better and stay one step ahead.
A second compelling benefit to the developer is the potential to generate a recurring transaction based revenue stream. End users pay per transaction performed. Through a partnership with the TPP you have the potential to see a portion of these fees. You can quickly recoup development time and produce a reliable ancillary income stream.
What Can A Business Use ACH Processing For?
• Recurring Payments: Automate the task of collecting or making a recurring payment.
- Automatically electronically draft a customer’s checking or savings account on a monthly, bi-monthly or other time frame.
• One-time payments: Accept a payment via the phone or fax and electronically have funds withdrawn from the customer account and deposited into a specified account.
• Processing Pay-Outs: Pay suppliers, affiliates or bills you can make these payments electronically and automatically.
• Direct Deposit: Employees can be paid electronically.
• Mailed Payments: New NACHA (www.nacha.org) rulings allow the conversion of a mailed payment into an electronic transaction. No more bank trips. Conventional lockbox (mailed payment processing) transactions can also be converted to electronic transactions)
Integration Methodologies
A one platform solution for processing both ACH (checking, savings account debits) and credit card transactions offers considerable time and development costs as opposed to distinct processing paths.
Transactions may be processed in batch mode or live (singletons). Batch mode might be used for recurring monthly billing cycles. Live processing would be used for a one-time debit (eg check or credit card by phone) where an authorization was required.
Batch transactions may be uploaded via secure FTP and reporting pulled down in much the same way. There are options for uploading transaction data but are typically specific to the Third Party Processor. The raw reporting pulled back via the FTP mechanism may then be parsed out to update the client’s accounting package. This becomes a serious time savings tool that clients quickly learn to love.
Live Transaction Processing Overview
There are many different ways to integrate but all methods utilize the industry standard Secure Socket Layer protocol (SSL). Most if not all (.Net/ASP/Java/Perl/PHP etc) programming methods are supported. If you do not see a preferred method here the TPP in all likelihood can meet your needs.
Secure Socket Layer (SSL)
SSL is the industry standard for data encryption over the internet. Browsers use SSL for secure websites. The way SSL works is that the server (i.e. website) has a “secure certificate” from a trusted authority (i.e. Verisign) that the client (i.e. browser) can verify. Websites without a secure certificate cannot publish secure pages (see SCI below). All the integration options utilize SSL for secure communications between the developer and processing servers.
Direct Socket Integration
This method connects the merchant directly to transaction processors via an SSL socket connection. This delivery method is very simple. Once the SSL library is initialized, the messages are written and read as with normal socket operations. The messages are typically in plain ASCII and delimited by newline characters. A new connection is required for each transaction. It can be used in any environment in which SSL sockets are available (either natively or through third party API’s).
XML Web Service
Developers will use XML standards and use the TPP’s guidelines.
COM Object
The COM Object is available to those in the Windows environment. It is a standard, registered Windows COM object that handles the (secure) transport of the authorization message and returns the response message to the caller. It actually connects to the Payments Gateway web server (sending a secure HTTP POST similar to that described in the next section). Code examples typically are included with the object’s DLL files. It can be used in the Windows environment via Visual Basic, ASP or any other platform that is COM-capable.
HTTPS POST
This method uses a secure HTTP POST operation to transfer the message data. It is useful as many environments now have secure HTTP libraries built in (as opposed to SSL socket libraries). The POST itself will consist of the messages name/value pairs (i.e. pg_merchant_id=99999) delimited by ampersands. The response can be returned as a (non-HTML) newline delimited message or as an HTML GET statement (with ampersand delimited name/value
pairs). It can be used in any environment that supports secure HTTP operations (either natively or through third party APIs).
Secure Certificate-Less Integration (SCI)
This is the method of last resort for those merchants that do not have a secure certificate (and thusly cannot collect payment information on their own). They collect the order information and forward their customers to our secure payment pages to complete the transaction. The simple linking method used to do this in the past has been scrapped because of security concerns. SCI uses a secure certificate to provide secure communications between the merchant and TPP. It is a little convoluted, but protects the customer’s financial data and the merchant’s transactional integrity. Again, this is a method of last resort. It is preferable that the merchant obtain a secure certificate, collect their own payment information and use DSI or the COM object.
Overview of ACH Processing
What is the Automated Clearing House or ACH Network?
The ACH Network is a highly reliable and efficient nationwide batch-oriented
electronic funds transfer system governed by the NACHA OPERATING RULES which provide for the interbank clearing of electronic payments for participating depository financial institutions. The American Clearing House Association, Federal Reserve, Electronic Payments Network, and Visa act as ACH Operators, central clearing facilities through which financial institutions transmit or receive ACH entries.
Flow of an ACH transaction and terms defined
An ACH transaction is an electronic request for funds transfer. It is important to distinguish request from actual transfer. Funds are NOT moved instantly. The transaction flows to the Federal Reserve System and proceeds as if the requisite funds to be moved are present in the consumers account. The two banks communicate electronically as to whether the funds were present. The transactions take 4 days to settle. A credit card transaction captures funds at the time of sale so you know you will be paid.
Originator
Any individual, corporation or other entity that initiates entries into the Automated Clearing House Network
Originating Depository Financial Institution (ODFI)
A participating financial institution that originates ACH entries at the request of and by (ODFI) agreement with it’s customers. ODFI’s must abide by the provisions of the NACHA Operating Rules and Guidelines.
Receiving Depository Financial Institution
Any financial institution qualified to receive ACH entries that agrees to abide by the NACHA Operating Rules and Guidelines.
Receiver
An individual, corporation or other entity that has authorized an Originator to initiate a credit or debit entry to a transaction account held at an RDFI. Typically your funds are available to you four days after your transactions are processed. There are several reasons for this delay but primarily it is because an ACH transaction is not an instantaneous movement of money. The transaction proceeds as if the money being debited is available. The two banks involved (ODFI and RDFI) have four days to get the details sorted out.
Case Study
Perennial Software (http://www.sedonaoffice.com) provides management software to security alarm companies. Their product is a highly regarded business and accounting management tool. Their management team was looking to embed payment processing via ACH and credit cards into their Sedona Office product suite. They astutely realized that there were several important considerations:
- Finding a one-platform solution to process both ACH and credit card transactions.
- They needed one processor as opposed to performing development work for each client to work with their existing bank or credit card processor.
- Transaction reporting was paramount to their end user. Being able to post payments and complete the payment cycle is an essential component of their accounting package.
Their talented software development team was able to successfully integrate the ACH and credit card payment processing components as well as the automated posting of payments.
A potential Perennial software user they were speaking with was processing over 10,000 payments per month from their alarm monitoring base. They were manually creating a batch file to be processed and were then receiving faxed reports regarding transaction history. They would then have to manually post payment data. In many instances they would wait weeks to find out a payment they assumed was good had come back as a non-sufficient funds payment or closed account. Being able to offer a management product also capable of processing electronic payments, posting those payments and completing the payment cycle made the Sedona product very attractive. By meeting these and other specific needs Perennial was able to secure the client.
The client was very quickly able to realize substantial time and money savings and had the following to say about the process:
“ We’ve realized many benefits from the payment processing integration with Sedona. The simplicity is the most obvious. It takes just a few seconds to submit a large batch of transactions to for payment processing. The turn around for funded transactions is impressive with a 24-hour turnaround for Credit Card payments and 4 days for ACH payments. We are also provided a variety of reports that are very helpful. Specifically, the Settlement Detail report is exceptional. It always matches up exactly with our bank statement deposits.
More importantly, this report allows us to track down and isolate previously funded, but subsequently rejected transactions as part of our daily reconciliation effort. In addition, we utilize the Live Transactions functionality available in Sedona. This allows us to pre-authorize a transaction through to ensure funds are available before submitting for payment processing thereby reducing costs and improving Customer Service. ”
By offering an integrated payment processing solution Perennial has a very satisfied software user that will in all likelihood remain a long time client.
Perennial was able to offer the payment processing capabilities to their existing customer base and court new clients with their payment processing solution. Perennial was able to cement their relationships with the legacy clients and bring on new customers based on their unique product.
Payment processing certainly is not the only reason Perennial Software has been able to garner its many users. They offer an excellent product meeting many needs but by integrating and embedding payment processing solutions as well as continually adding value to their product they have a competitive moat around their business and are considered a best of breed product.
Summary: By integrating a payment processing solution your company can create a competitive moat that distinguishes your software product or ASP from those in your market space.
As explained there are a variety of techniques to send/receive transaction data and most processors are flexible enough to accommodate your specific needs.
In determining if payment processing integration is a fit for your team you must ask the question: “Will my product be better for my end user by having payment processing functionality?” If the answer is yes then you can bet that if it is not you offering this feature your competition may be the one building the moat.
ACH-Payments.com is a leading provider of ACH and credit card processing tools to businesses across the US.
