Investopedia states that “A payments gateway is a technology used by merchants to accept debit or credit card purchases from customers. The term includes not only the physical card-reading devices found in brick-and-mortar retail stores, but also the payment processing portals found in online stores.”
This definition suggests that you send a request for funds to a gateway, and once through the gate, it disappears into the ether to do whatever it needs to do to ensure funds are debited from your account. Goods or services are then delivered in return. But there’s much more that a modern retailer needs.
In the early days of eCommerce payments, a payments gateway was a simplistic “middleware” solution connecting merchants to the acquirers—a simple black-box solution for which the term could reasonably apply.
But year after year, the business of processing a payment has become increasingly complicated: EMV, PCI DSS, 3DS, P2PE, GDPR, SCA and so on. Payment processing is no longer—and arguably never was—a case of simply transmitting a payments request to a gateway or a black box and on to the acquirer.
What’s in a name?
The danger is that the simplicity of the “payments gateway” label leads to simplicity of expectation—and failure to appreciate the full complexity of a payments service. If you don’t recognize what is really needed in a solution to process payments for a retailer, you can’t discriminate between them.
No two payment gateways are the same, but broadly speaking, the requirements of a payments gateway can be split into front and back ends. The back end is probably the part that most resembles a gateway and is where the term originates. In the early days, this was usually a connection to one acquiring bank, but now this needs to be a gateway to a network of payment destinations – multiple acquiring banks, multiple payment methods in multiple countries with multiple currencies. And that’s just a start; there’s also a need to determine the best destination for the payment, when and how best to apply strong customer authentication (SCA), whether to attempt the transaction again if the payment is declined and how best to screen fraud without losing good customers. All this needs to be optimized to maximize customer conversion and minimize fraud.
At the front end, successful eCommerce requires a slick, intuitive means to take payment credentials from the shopper and simplification of—or better still, exemption from—the SCA process.
For in-store payments, the back-end connectivity to a variety of payment acquirers and methods increases payment options for customers, thereby improving the customer experience and conversion rates. There’s also the need to provide a means to drive payment terminals in the store and integrate with the in-store software—and remotely configure and monitor them. This is complicated by the growing need to support point-to-point encryption to ensure that card data cannot be compromised.
And, for those retailers that trade both in-store and online, there’s often a need to tokenize transactions for security benefits as well as be able to better serve customers with a truly omni-channel service, allowing shopping behaviors like click-and-collect and buy-online-return-to-store.
Finally, all of this needs to run 24×7, be reliable and responsive, secure, allow for continuous processing and provide a means to settle with other parties, analyze transaction data and generate management reports.
That sounds like much more than a gateway to me. I would call it a payments hub.