With the rise of eCommerce and mobile payments, gateways play an increasingly important role in the payments ecosystem. Unlike the simple payment gateways of a decade ago, modern gateways are increasingly diverse, and oﬀer features and value-added services for merchants of all kinds.
As gateways have proliferated, the variety of gateway providers has grown as well. In this paper, we review the function of payment gateways and the role they play in payments. We also consider some of the diﬀerent types of gateways, and oﬀer criteria that merchants, ISVs and developers can consider in determining the gateway solution that is right for them.
WHAT IS A PAYMENT GATEWAY?
Definitions vary, but a payment gateway is generally understood to be a software accessible interface provided to various types of merchants that facilitates card or other forms of electronic payments. Gateways are often associated with eCommerce applications, but they serve a variety of needs:
- Providing payment services for eCommerce, mobile applications, virtual terminals and various types of point of sale solutions
- Presenting simplified interfaces that make it easier to add payment functionality to websites and other applications
- Helping integrated software vendors (ISVs) avoid the need to code to particular payment processors, thus providing portability and allowing merchants to shop around for services
- Oﬀering value-added services including reporting, analytics, anti-fraud features and interfaces to various third-party accounting platforms (services increasingly available through payment gateways)
HOW PAYMENT GATEWAYS WORK
To understand how gateways work, it’s useful to view their role in the context of the overall payments ecosystem. When consumers make an electronic purchase using a credit or debit card (or a digital or mobile wallet backed by stored credentials) a variety of players from banks to credit card companies to payment processors cooperate to facilitate the transaction. The process can vary depending on the nature of the gateway and payment, but Figure 1 provides a simple illustration of the payment process.
What makes this a little complex is that multiple parties can operate a gateway. For example, a merchant’s bank (the acquiring bank) may act as the payment processor or have a relationship with a payment processor. In some cases, a payment processor will operate their own gateway, and in other cases the gateway will be operated by a third party. In other cases (not shown in the diagram) a gateway might route transactions through another gateway to oﬀer a great number of back-end processors. In fact, often a transaction will traverse multiple gateways before a payment is finally processed.
REGARDLESS OF THESE SUBTLE DIFFERENCES, THE PAYMENT PROCESS IS ROUGHLY AS FOLLOWS:
- The consumer makes a purchase: The consumer starts by presenting their payment credentials to a merchant. This can be done in a variety of ways including keying a card number on a website, using a mobile app, swiping or dipping a card at a point of sale.
- The merchant relays the payment request to a gateway: Merchants may have their own custom application (a website or mobile app for example) or they may rely on a third-party shopping cart or integrated point of sale provider already integrated to a gateway. Increasingly, gateway providers oﬀer secure ways to pass payment credentials directly from the consumer to the gateway bypassing the merchants’ environment. This is usually done by using a hosted checkout page, exposing sensitive fields in an iFrame served by the gateway, or by using Tokenization to convert payment credentials to a non-PCI sensitive value.
- The gateway provider receives the request: When the gateway provider receives a transaction, they typically relay authorizations or other instructions to a payment processor. Some large gateways have relationships with a specific processor, while others have connections to multiple processors.
- The payment processor facilitates the transaction: On receipt of a request from the gateway, the payment processor relays the request to the appropriate card brand that will in turn route the request to the appropriate issuing bank for authorization. Assuming there are sufficient funds and the account is in good standing, the bank and card brand will relay an approval back to the processor that will in turn be relayed to the gateway and ultimately the merchant. The payment processor facilitates the movement of money from the cardholder’s issuing bank (who are essentially loaning the consumer money until they pay their credit card bill) to the appropriate merchant bank account.
TYPES OF PAYMENT GATEWAYS
While most transactions involve a ﬂow like the one above, gateways can take diﬀerent forms. There are hundreds of diﬀerent payment gateways catering to specific market requirements. While not an exhaustive list, consider these diﬀerent types of gateways.
Hosted payment gateways – With a hosted payment gateway, the gateway provider hosts a checkout page on their own servers, and a web application directs users to this page when it is time to process a payment. This solution is popular with some eCommerce developers because hosted pages are easy to integrate, and are generally web and mobile web friendly. Also, online merchants may reduce PCI scope by relying on the gateway provider to secure the payment page and handle sensitive information. A potential downside is that while many solutions try to make this process seamless, consumers often know they are being directed to a diﬀerent site. Examples of this type of gateway include PayPal Payment Standard, 2Checkout and Vantiv hosted checkout solutions.
Direct gateways oﬀered by payment processors – Major payment processors often provide their own gateways to simplify connections to their core payment platforms and in some cases other platforms as well. The advantage of dealing directly with a processor is that they may oﬀer better pricing (because there are fewer intermediaries involved in the transaction), they can be faster and more reliable because there are fewer “hops”. A potential downside is that even the relatively simple gateways oﬀered by major processors can be more difficult to code to because they often expose a richer feature set requiring a greater knowledge of payments. A processor provided gateway may also provide better success rates in authorizing payments because the processor has full access to all the capabilities of their core payment systems. Additionally, they can structure transactions to maximize chances of success while also lowering interchange fees.
Unlike more basic eCommerce-only gateways, a payment processor may provide additional features supporting card present, point of sale functionality as well as card not present functionality. Payment processors may also oﬀer the same interfaces described above including hosted payment functionality, SDKs and REST APIs. Examples of processor provided gateways include Vantiv’s Express Gateway, Vantiv’s eCommerce gateway, First Data’s Global Gateway, First Data’s Payeezy gateway, and Chase Paymentech’s Orbital Payment Gateway.
Platform-centered gateways – Platform-centered gateways provide an infrastructure that allows merchants to oﬀer goods and services directly from a full-service payment platform. Rather than develop their own applications, some solutions in this category allow merchants to maintain their own catalog on the platform itself and present a branded online storefront. Platforms of this type can solve a variety of issues for merchants including avoiding costly development or integration eﬀorts and handling issues like internationalization, multi-currency support and a broader set of payment methods popular in diﬀerent locales. These platform-centered gateways may in turn connect to other gateways, and this may or may not be selectable by the merchant. Examples of platforms that ft this model are BlueSnap, Gate2shop and Shopify.
Gateway aggregator – A gateway aggregator presents a simplifed programming interface to developers and ISVs and also provides “back-end integrations” supporting a variety of other payment gateways. In a sense the aggregator acts as a gateway “switch”. This allows a developer to code their application to a single API and transparently support a wide variety of other gateways when they go to market. Using this type of gateway, an ISV can oﬀer a merchant their choice of gateway while minimizing their own coding, integration, testing and maintenance eﬀorts. A potential downside of this “one size fts all” model is that feature sets tend to be watered down. By supporting the “least common dominator”, more advanced features of some gateways become inaccessible. Also, every transaction goes through an additional “hop”, and there is one more player in the already complicated payments ecosystem that needs to be compensated for each transaction. An example of a gateway provider that fits this model is Spreedly.com.
CONSIDERATIONS WHEN CHOOSING A GATEWAY
With literally hundreds of payment gateways available, choosing the right solution can be daunting. Unfortunately, there is no single right answer for all organizations. Diﬀerent merchants have diﬀerent needs, and not all organizations will see value in the same features. To provide a basis for comparison, some potential criteria to consider when evaluating gateways are suggested below. An ISV or merchant can decide what considerations are important to them, and weigh the value of each attribute accordingly.
Cost per payment transaction – For most merchants, cost is always an issue. A diﬀerence of 0.2% in an average cost per transaction may not sound like a lot, but for a small business with five million dollars in annual receipts, this represents $10K to the bottom line. Gateways often publish what are referred to as “discount rates” – for example $2.9% plus a fixed cost per transaction with a tiered discount schedule as volumes grow. Larger payment providers may oﬀer “interchange plus” schemes where merchants pay actual interchange fees and assessments plus an additional fixed fee for processing services. These types of processing agreements may be subject to additional fees as well. While interchange plus fees can be more complex, larger merchants often prefer them because they provide visibility to the component costs of each transaction. Understanding all the details of the fee structure including potential extra costs related to refunds, chargebacks and miscellaneous fees is important regardless of the payment solution you select.
Percentage of transactions that complete successfully – A consideration often overlooked is the percentage of Authorizations and Captures that complete successfully on a gateway. This is arguably even more important than minor diﬀerences in the cost per transaction, because failed authorizations can translate directly to lost business and a reduction of top-line revenue. This is an area where the gateways oﬀered by larger payment processors often have a significant edge over third party gateways. Tier-one eCommerce gateways have success rates for completed transactions in the range of 95%, whereas better known brand name gateways often fare poorly with success rates in the 80% range.¹ This critical conversion consideration is important for most merchants, so developers and ISVs should consider this carefully as well when choosing a gateway.
1. The Payment Gateways Report – August 2016 – Evan Bakker, BI Intelligence
Type of bank account required – Another consideration is the type of bank account required for use with the payment gateway. Most gateways will require that the merchant have a merchant bank account and their own Merchant ID (MID). Other gateways essentially act as aggregators, collecting payments themselves and then distributing them to a merchant’s bank account periodically or as requested using ACH transfers. This second model allows smaller merchants to use a regular bank account and get up and running quickly avoiding the need to have a MID and the fees involved with a merchant account. PayPal and Stripe are examples of payment gateways that allow for this. While this is an option, merchants doing a reasonable volume of sales, needing fast settlement will generally be better served by having a proper merchant account.
Support for card present / point of sale applications – Many popular payment gateways are built specifically for eCommerce transactions. This is logical, since most businesses adding an online storefront already have established point of sale solutions, and pure play eCommerce providers may not need one. As the lines blur between traditional retail and online commerce however, it is useful to have a single payment infrastructure for both online and in-store payments. Not only does aggregating volume help reduce rates, this can be useful when oﬀering capabilities like order online, pick up-in store, order-ahead, in-store refunds for online purchases, and other capabilities that consumers increasingly demand. Some gateways oﬀer features required for point of sale payments such as batch processing, lane management, support for various terminal devices (card readers, EMV, pin pads etc.), and vertical application extensions for auto rental, lodging, healthcare and other industries. For merchants that hope to use a single payment solution for both in-store and online channels, support for card present features can be important criteria when selecting a gateway.
Ease of integration and maintenance – For some developers or ISVs, ease of integration can be an important consideration. Some application gateways are developer friendly oﬀering hosted payment pages or easy-to-use SDKs implemented in multiple programming languages. Some gateways even oﬀer SDKs targeting specific mobile platforms like iOS or Android supporting use-cases like in-app or mobile web wallet purchases. Other payment gateways don’t oﬀer SDKs, but provide an interface specification instead (usually accessed via a REST or SOAP / XML POST API) where client applications send and receive payment transactions that they encode themselves in XML or JSON formats. There are pros and cons to each solution. Some developers will prefer an SDK, but others view SDKs as problematic since they introduce a dependency on their code that can complicate the release management process. These developers would prefer to code directly to a specification where they have full control, even if it means more coding eﬀort. There is no right or wrong answer, but understanding the nature of the developer interface is also an important consideration in choosing a gateway.
Throughput & performance – Another factor in selecting a gateway is performance. Gateways often pass payment data through multiple providers, and each additional “hop” introduces latency and increases opportunities for errors or outages. Payment approval times can range from sub-second response times to several seconds or even tens of seconds depending on the gateway directly aﬀecting the user experience. Generally, the closer the gateway is to a payment processor, the better the performance and reliability will be.
Breadth of payment processors supported – For ISVs, it can be advantageous to support multiple payment processors. This is often an argument for coding to a third-party gateway, for this reason alone. Some gateways have an established relationship with a single payment processor (e.g. Stripe) whereas other gateways support multiple processors (e.g. Vantiv’s Express Gateway). There is no right or wrong answer here either, but before selecting a gateway, it is important to understand how this might constrain your merchant’s choices in terms of payment processors and banking services.
Multi-currency Support – For online merchants selling internationally, multi-currency support is important as well. Multi-currency support should not be confused with accepting international cards. For example, a US domiciled merchant may sell goods or services to a Canadian resident where the amounts are presented and paid in US dollars, so multi-currency support is not strictly necessary. Organizations selling internationally will see value in gateway solutions that allow customers to pay in their home currency however as this will increase conversions and sales. Consumers prefer to pay in their home currency for a variety of reasons including concerns about noncompetitive currency exchange rates that may be levied by banks or credit card companies.
For merchants and ISVs, selecting the right payment gateway is an important decision. Diﬀerent gateways have diﬀerent strengths and weaknesses, and the right solution will depend on your unique needs and the merchants and customers that you serve.
VANTIV’S EXPRESS GATEWAY
For developers building point of sale, eCommerce or mobile payment solutions, Vantiv Integrated Payments provides a variety of payment solutions. Vantiv’s Express Gateway is a high-performance, easy to use gateway that supports a wide variety of card present and card not present features making it a good choice for organizations building a wide variety of applications. It presents a straightforward XML interface that is easy for developers to understand and
code to. It also exposes rich functionality for multiple industry verticals and ensures that payments qualify for the lowest possible fees.
The Express Gateway is used by various Vantiv integration APIs such as Hosted Payments for card not present and MOTO environments. In addition, triPOS payment middleware can be leveraged with Express Gateway for card present environments, a distinct solution that makes it easy for point of sale developers to support EMV capable hardware without coding to each device individually. Because the gateway is operated by Vantiv it oﬀers excellent performance, and high transaction success rates. It also links to multiple payment processors and oﬀers features like hosted payment interfaces and features like PCI validated point-to-point encryption (P2PE) and tokenization to reduce PCI scope.
To learn more about Vantiv Integrated Payments solutions please visit
For technical information about Vantiv’s Express Gateway or other payment interfaces, developers can visit