By Brandes Elitch
Recently, someone asked me, "What does a processor do?" Misunderstanding about this subject abounds, even among ISOs who have been in the payments industry for a while. I hope this article will clarify the role of processors in our realm.
Some time ago, I was involved in building an acquiring business for a small bank that ultimately became a top 25 acquirer. The chief executive officer had made a decision early on that the bank would be an acquirer, which was an adventurous decision at the time.
(This was before the card companies, which were organized as card associations at the time, decided they did not want small banks as principal members, either on the issuing or acquiring side, and forced them to use a service bureau or consolidator.)
In the course of my calling efforts, I visited with someone who later became an ISO for us, creating and then selling two of the most successful ISOs for upward of $100 million (yes, really). I will never forget his reply when I commented about his business model: "Yes, but I want to be a processor; that's where the real money is."
I also remember the first time I saw the monthly statement from our processor. Coming from a large bank, cash management environment, I was familiar with how an account analysis works, since I had to explain it to large enterprise clients.
However, I was unprepared for our processor's statement. It was probably 50 pages of undecipherable, coded entries. Our CEO's most memorable comment at the time was that the good thing about our processor was that it treated all its "clients, big or small, equally badly."
What is it that is so mysterious about being a processor, and why, in an industry as large as the acquiring industry, are there only a handful of players? What are the implications for ISOs?
First, there are two types of processors: front-end, and back-end. The front-end processor handles the capture, authorization and settlement with the acquiring banks; has connectivity to all the card companies; and routes transactions to the appropriate network for authorization.
When a merchant submits a batch of payments, it goes to the front-end processor, which routes it to the back-end processor.
A back-end processor accepts the settlement from the front-end processor and then moves the money from the issuing bank to the acquiring bank.
When it gets settlement batches, it groups them by bank identification number range and submits them to the issuing banks within a scheduled time frame.
Some companies are both front-end and back-end processors; some large acquiring banks can be processors too.
The front-end process works as follows:
Settlement is a subsequent process consisting of the following five steps:
A payment gateway may be in the loop, too. This is typically the case for web-based transactions. A processor cannot always connect to every payment application a merchant wants to use.
But a gateway might do that, interfacing to different POS systems, Internet providers, and other types of input besides traditional POS devices such as call centers and MO/TO and mobile devices.
The gateway is the front-end connection to the card companies, but gateways can do more than bridge transactions. For example, they can provide detailed, customized reporting; fraud control; reconciliation tools; customer support; scalability; and compliance.
Authorize.Net (owned by Visa Inc. subsidiary CyberSource Corp.) explained the role of gateways in its marketing materials as follows: "Connecting a website to the payment processing networks is exceptionally difficult and typically beyond the expertise and technical resources of most online merchants. Instead, merchants can connect to the gateway, which provides the complex infrastructure and security necessary to ensure fast, reliable and secure transmission of transaction data, using the Internet instead of a telephone line."
Obviously, we are transitioning to an environment where consumers will increasingly pay with cell phones or online via the Internet (another card-not-present scenario). This is where processors can differ dramatically from a pricing standpoint. When the card brands increase their fees (historically in April and October), some processors take advantage of this to raise their fees, too.
Processor fees can include security, membership, access and compliance fees. I have a list of 28 fees you might find in a processor statement (contact me if you want to see it).
Sometimes a statement will not show these fees until the month after a given transaction occurred.
Robert O. Carr, CEO of Heartland Payment Systems Inc., mentioned several other questionable processor practices:
Since most merchants never read their statements (a bold proclamation, but I stand behind it), they never see these charges, nor do they understand the true cost of what they are buying. I have asked hundreds of merchants what they are paying for credit card processing, and the answer is invariably a figure like 1.5 percent. It's just like when I buy a used motor from the wrecking yard: I ask how many miles it has, and the answer is always, "Eighty thousand." You can bet on it.
One of the most important things a processor can provide is data security. A lot of data flows through a large enterprise, particularly one with multiple consumer touch points. Everyone talks about end-to-end encryption, but some of what occurs is just point-to-point encryption. True end-to-end encryption starts when the card is swiped and continues through the terminal, the wires and the host processing network until the processor hands it off to the card networks.
Until recently, the card brands didn't want to receive encrypted files, but they are now able to handle them. Encryption also applies when loading applications into terminals. Up to now you could usually add any application you wanted, but inherent weaknesses in the process tend to be in the software and can only be remedied by using the right hardware, such as tamper resistant security modules or hardware security modules. This is something to discuss with your processor.
Fewer than a dozen processors handle almost all of the credit card transactions in the United States. Starting a processor takes years, not months, and the programming and data processing requirements are well beyond the range of most ISOs.
Another consideration: significant capital is required to convince the issuing and acquiring banks and the card companies that you can be responsible not only for delivering files timely and accurately, but also securely. The cost of not doing so can be in the tens of millions of dollars.
At this point, the barriers to entering the processing field are formidable. My advice is to focus on building a better ISO instead, and educate yourself on the distinctions among the existing processors.
We are about to see some of the biggest changes to the payments system in recent years. Each processor will respond differently and, as an ISO, you will need to know the details - for the sake of your merchants and for yourself, too.
Brandes Elitch, Director of Partner Acquisition for CrossCheck Inc., has been a cash management practitioner for several Fortune 500 companies, sold cash management services for major banks and served as a consultant to bankcard acquirers. A Certified Cash Manager and Accredited ACH Professional, Brandes has a Master's in Business Administration from New York University and a Juris Doctor from Santa Clara University. He can be reached at firstname.lastname@example.org.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next