There are two main functions of Payment Gateways: core functions and value-added functions. Core functions cover end-user-oriented payment functions and merchant-oriented acquiring services, while the value-added functions include functional support across the business lifecycle.
The payment function is the core function of Payment Gateways. Payment functions include supporting transactions across a wide range of banks, card institutions, third-party payments, as well as technical indicators such as payment success rates, payment processing speed, and system stability. Larger Payment Gateways have wider coverage of banks and third-party payment types, more reliable technology, and higher fees. However, these large-scale Payment Gateways often only offer limited functionality and support for small local banks.
If a merchant needs to receive money through electronic payments, they have to apply for a special kind of bank account with an acquiring bank that can meet their legal compliance and banking requirements. The purpose of an acquiring service is to significantly reduce the cost of negotiating with banks, applying for accounts, and communicating between parties when problems arise.
Common value-added functions of Payment Gateways include pre-authorization, refunds, cancellation of payments, batch payments, timed automatic payments, dynamic currency conversion, multi-currency pricing, reports, and queries. Different combinations of value-added functions are a significant differentiator for Payment Gateways.
We recommend assessing value-added functions based on your actual requirements. If a function isn’t required to support core business needs, it can be gradually incorporated into your delivery plan, and doesn’t need to be a focus upfront.
When it comes to choosing the functionality you need from Payment Gateways, the best course of action is to let your decision be guided by the needs of your business and your users:
A small or medium-sized Payment Gateway with a favorable brand reputation, local banking support, and the most popular local third-party payments method enabled should likely represent the best option for smaller, locally-operating businesses. However, a lack of support for international transactions and business can constrain their future growth plans — forcing organizations to change gateway as they grow. However, it’s possible to navigate around that challenge by isolating code in advance to support future expansion.
For international business, different countries and regions have distinct payment method requirements which will impact the selection of Payment Gateways. In this case, I recommended choosing Payment Gateways that contain the mainstream third-party payment methods favored in each region you operate in. When integrated with such a Payment Gateway, you can meet the needs of multi-regional users, and the integrated technology can be used for further implementation. For example, the initial code used to build structures and interfaces for integration with PayPal through Worldpay could be used again later when you want to extend support to AliPay or WeChat, with just a few configuration changes.
Whatever the size of your business, I recommend that you put a strong focus on acquiring services when evaluating Payment Gateways. If your chosen Payment Gateway offers acquiring services, you can significantly simplify processes, communication, and technology, because you’ll only ever need to deal with the gateway directly, never third parties or specific financial institutions.
While assessing these technical capabilities, it’s important to recognize that it takes multiple systems to effectively process a payment, and that it’s very common for problems to arise across those systems. These problems can be costly, so merchants need to do all they can to protect themselves against them. Here are four actions you can take during your selection and implementation process to test the robustness of solutions and safeguard against expensive processing problems in the future:
Don’t just take the technical specifications promised on the Payment Gateway's official website at face value. Formalize those specifications and expectations in an SLA (Service Level Agreement) to protect your rights and ensure you get what you’re expecting.
Add effective monitoring and logging into your system to support Payment Gateway troubleshooting and make it easier to locate the sources of problems when they happen.
Test the stability of the interface to verify that it can identify Payment Gateway failures promptly.
Implement a reasonable set of fallback mechanisms, such as the ability to toggle off the broken down Payment Gateway or switch to another Payment Gateway. This can help you minimize the impact a Payment Gateway going down has on the business and users.
In part 3, we will explore the security capabilities of Payment Gateways. You can find part 3 under ‘related content’ below.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.