Gateways & APIs

A large number of merchants processing Card-Not-Present (CNP) transactions connect to their payment processors through a “payment gateway”. Payment gateways generally offer “Software as a Service” (SaaS) solutions, acting somewhat like a payment processor. Examples of some SaaS payment gateways include Verisign®, CyberCash® (bought by Verisign and sold to PayPal), CyberSource®, and Authorize.net® (now owned by CyberSource).

These third-party gateways originated primarily as switches, routing payment transactions between Web merchants and traditional payment processors. These companies were not considered payment processors or acquirers because they were not sponsored by member banks and did not take liability for the transactions passing through their systems. At the time, the greatest values these companies generally offered were their real-time interface and rudimentary fraud detection services. Over time, however, payment gateways began to diverge into two camps, one group enhancing their value-added services, the other group maintaining their position as a switching platform and focusing on smaller merchants.

A good example of a company investing in value added services would be CyberSource. Originally a payment gateway with certain fraud detection services, the company evolved into a bank sponsored ISO. CyberSource also enhanced its value-added services to include global processing, credit card data outsourcing and payment security amongst others.

It is interesting to note that over time, conventional payment processors began to offer real-time processing and fraud services of their own. In many cases, and especially for larger merchants, this trend marginalized gateways remaining in the switching platform camp. This part of the industry has therefore seen significant consolidation over the past several years, with some vendors leaving the business altogether.

Gateway vs. API, A Common Misnomer

Parallel with the proliferation of the SaaS gateways, other companies began to develop commercial shrink-wrapped software solutions for Web merchants. These packages either provided human user interfaces to payment processors (PC-based virtual credit card terminals), or shipped as “plug-ins” for e-Commerce, ERP and shopping cart systems. Some examples of the former would include PCCharge™ by VeriFone® and ICVerify® by First Data. An example of the latter would be iPayment by Oracle®. Because the primary purpose of these software packages is to provide an interface with payment processors, they are actually considered Application Programming Interfaces (APIs), and not gateways. Credit card neophytes will often contact payment processors and request gateway documentation, when in fact, they are looking for an API they can program to. Unlike gateways, APIs will likely never be obviated; merchants will always need to communicate with their processors, and even payment gateways must have an API.

Payment gateways and “Noise”

While there are distinct differences between gateways and APIs, they both have the potential to harm Interchange qualification. An important electrical engineering principle states that whenever you add a component into a circuit, it adds some level of “noise.” Although not a perfect analogy, this principle does apply to data processing in the payments industry. If you add a gateway or an API between your system and your payment processor, you introduce the possibility of generating noise. In this case, the noise is generally created by the introduction of new data formats and connectivity methods. After all, your system data must be converted to a format the gateway or API understands, and the gateway or API must then convert the data to a format your payment processor understands. It is not uncommon to lose certain data elements along the way. The situation potentially becomes even more convoluted when you consider that your payment processor manages APIs with the card Associations, and subsequently the Card-issuing banks!

Sometimes the communication failure is caused by a deficiency in the gateway or API. More often, however, data loss is caused by a failure in the implementation of an API, or by an error in configuring the gateway or API. In some cases, the gateway or API are simply not designed to optimize certain aspects of processing like interchange. A corollary to our electrical engineering analogy states that if you remove an unnecessary component from a circuit, then the noise will be removed. As a matter of principle, merchants should consider eliminating any gateways unless the gateway provides some valuable service unavailable directly from a payment processor. Viewed from a less technical perspective, this would be known as “eliminating the middleman” or “going direct.” By doing so, you will most certainly be reducing the probability of introducing errors into the system and certainly reduce your costs. Merchants should be certain; however, that the payment processor they choose has an API with the data structures necessary to achieve optimum Interchange