Is Your Payment Gateway Right for Your Business?

Document created by lsolheim on Jan 21, 2018Last modified by Worldpay Developer Community Support Team on Feb 1, 2018
Version 16Show Document
  • View in full screen mode

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 offer 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 different types of gateways, and offer criteria that merchants, ISVs and developers can consider in determining the gateway solution that is right for them.




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
  • Offering value-added services including reporting, analytics, anti-fraud features and interfaces to various third-party accounting platforms (services increasingly available through payment gateways)

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 offer a great number of back-end processors. In fact, often a transaction will traverse multiple gateways before a payment is finally processed.

payment gateway


  1. 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.
  2. 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 offer 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.
  3. 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.
  4. 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.


While most transactions involve a flow like the one above, gateways can take different forms. There are hundreds of different payment gateways catering to specific market requirements. While not an exhaustive list, consider these different 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 different site. Examples of this type of gateway include PayPal Payment Standard, 2Checkout and Vantiv hosted checkout solutions.

API accessible gateways – Merchants that want more control over the checkout experience will prefer to host their own checkout pages. They may use a third-party shopping cart, rely on application ISVs, or use consultants or in-house developers to build their own applications. In these scenarios, the merchant’s application or website will interact with the gateway provider for various payment transactions (Authorizations, Captures, Refunds etc.) using an SDK or an XML or JSON interface. These types of gateways offer more flexibility, but they can increase the PCI DSS scope because merchants may need to handle, store or transmit cardholder data. Often these solutions are supplemented by JavaScript libraries that Tokenize sensitive data prior to transmission, helping keep applications out of PCI-scope. Examples of gateways in this category are Authorize.Net, Worldpay and Stripe


Direct gateways offered 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 offer 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 offered 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 offer 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 offer 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 efforts and handling issues like internationalization, multi-currency support and a broader set of payment methods popular in different 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 offer a merchant their choice of gateway while minimizing their own coding, integration, testing and maintenance efforts. 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

With literally hundreds of payment gateways available, choosing the right solution can be daunting. Unfortunately, there is no single right answer for all organizations. Different merchants have different 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 difference 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 offer “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 differences 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 offered 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 offering 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 offer 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 offering hosted payment pages or easy-to-use SDKs implemented in multiple programming languages. Some gateways even offer 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 offer 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 effort. 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 affecting the user experience. Generally, the closer the gateway is to a payment processor, the better the performance and reliability will be.

Security, encryption and PCI scope – How the gateway handles sensitive cardholder data is another key consideration for both merchants and developers. Most gateways offer hosted payment solutions, iFrame-based solutions, or JavaScript libraries that vault credentials at the point of capture providing a low-value, non-PCI sensitive token to be used in place of the actual card number. Gateways may also provide a separate token in response to a payment transaction that can be safely stored in the merchant’s database to facilitate “card on file” functionality so that consumers don’t need to rekey their card for subsequent purchases. In selecting a gateway, it is important to understand features related to encryption and tokenization and avoid solutions that put the payment application in PCI scope. The same is true for gateways supporting card present solutions as well. Ideally the gateway should facilitate secure processing, using point-to-point encryption for any point of entry, including EMV, swiped, tapped or keyed transactions eliminating the applications need to store, handle or transmit card data. Breadth of payment methods accepted – An important strategy for maximizing conversions is offering multiple payment methods. Ideally, a gateway should support payments for all major credit and debit cards. Developers should also consider capabilities related to other popular payment methods like PayPal, MasterPass or Visa Checkout. Mobile wallet based payments are expected to increase in popularity in the coming years (Apple Pay, Android Pay and others) as consumers increasingly prefer “one touch” checkout for faster speed of service both instore and online.


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. Different gateways have different strengths and weaknesses, and the right solution will depend on your unique needs and the merchants and customers that you serve.

Learn more

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 offers excellent performance, and high transaction success rates. It also links to multiple payment processors and offers 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

Merchant Solutions - (ISV's, Express, triPOS, Hosted Payments, MercuryPay, Datacap, Docs) 


For technical information about Vantiv’s Express Gateway or other payment interfaces, developers can visit