When Glenbrook is Assessing a Merchant’s Payments Operations, the goal is to understand whether the payments environment functions in a way that optimally supports their existing business needs as well as any future requirements. To do so, one of the major Key Assessment Areas that we address is the technical architecture and services a merchant uses to process their payments.
The complexity of a merchant’s payments architecture can vary greatly. How well that architecture serves the merchant’s needs directly affects their ability to manage the costs associated with payment processing, the organization required to support it, and the customer experience. Merchants must balance numerous trade-offs when deciding on the optimal payment architecture for their unique needs and organizational objectives.
This post in our series on merchant payments operations examines the choices that merchants must consider when designing their payments processing architecture, and identifies some best practices that best-in-class merchants incorporate into their architecture and operations.
Payments Architecture Can Vary Greatly Across Merchants
An e-commerce start-up that just started accepting payments has a very different payments architecture compared to a global, omnichannel retail company that has been accepting electronic payments across channels for 15 years or more. The start-up has the benefit of the latest technology that was designed to streamline payment processing. Their focus is typically to get up and running as fast as possible, with minimal overhead, in order to immediately begin making sales. By comparison, the retail giant may be operating on legacy technology that struggles to accommodate rapidly evolving technologies and risks unanticipated by the original design. Developers supporting a sub-optimal payments architecture spend a significant amount of their time addressing technical debt, dealing with maintenance issues, and fixing bad code.
Across the variety of merchants that we have worked with, differences in architecture are often a result of the following factors:
Length of Time Accepting Payments
As above, a new company has the opportunity to leverage new technology built specifically for modern payment processing and for their specific use case while building, from scratch, the internal infrastructure and processes needed to respond flexibly to future demands.
Mature merchants have to measure whether their existing architecture and providers are meeting their needs now and for the foreseeable future. A mature merchant may have a direct connection to only one provider. That design has multiple ramifications:
- Limited Choices. The merchant’s ability to add new features is subject to whatever the provider has in its kit. Long lead times for new functionality are common.
- Vulnerability to Outages. A single vendor’s own infrastructure must be resilient. The merchant’s own operational requirements may well increase over the course of a contract. What was adequate reliability during year one may no longer meet the merchant’s availability requirements.
- Reduced Negotiating Leverage. Changing payment processing providers can be a multi-month, if not multi-year, project. Incumbent sole-source providers are fully aware of their level of account control as the merchant has no easy way to switch to a new provider without disrupting their existing business.
Acquisitions of New Businesses
A merchant may have acquired one or more businesses that had pre-existing payment processing infrastructure and provider relationships. This results in multiple payment systems for the organization’s IT team to support, additional vendors for the Operations team to manage, and multiple contracts that don’t take advantage of the combined merchant’s payment volume.
Business Units with Specific Requirements
It is not uncommon for large merchants with multiple business units to have one or more business units “go rogue” and select payment providers that fulfill specific requirements unique to their channel but are not aligned with the corporate “money team’s” priorities and design requirements. We often see this independent action because the existing architecture is not able to adapt to the needs of this business unit within an acceptable time frame.
How Many Acquirers Should a Merchant Use?
Merchant’s often begin processing with a single provider, as the initial need is to begin taking payments as soon as possible. However, even new merchants should consider that they may need an additional acquirer in the future, and build their architecture in a way that enables the ability to relatively quickly add that new vendor.
Using multiple acquirers comes with benefits and drawbacks:
Benefits. Multiple acquirers provide redundancy. Outages at acquirers are a matter of “when”, not “if”. Having another acquirer to route transactions allows the merchant to have faith in the resiliency of their system, reducing the risk of poor customer experiences when one acquirer is unable to process a payment.
Multiple acquirers provide the ability to compare price and performance, which provides negotiation leverage when evaluating routing logic to optimize authorization rates and in future contract negotiations.
Drawbacks. On the other hand, using multiple acquirers can make certain aspects of payments management more challenging. Rather than relying on a sole acquirer to provide tokenization services to protect from PCI exposure, the merchant may need to use a third party token provider to store card credential data. That adds another vendor into the mix.
Multiple acquirers also result in the need to normalize data across multiple providers.
Payments Architecture – Build or Buy?
In order for a merchant to accept payments, their payments architecture has to enable and support a multitude of functions. The merchant must decide whether they want to build these functions internally, or use a third-party provider. Primary considerations include budget, the cost of time to market, payments operations and engineering expertise, and product strategy, among others.
Internal Integration Layer
A centralized payments architecture can act as a central hub, to provide payment services to one or more business units by either controlling or tightly integrating with relevant billing and payment initiation systems. This central hub makes all relevant payment methods available to each business unit as needed.
Connectivity to Payment Providers
During a transaction, the payment data needs to be passed from the merchant at the point of sale – whether that is at the physical POS or through an online checkout form – to at least one payment provider in order to be routed to the network and ultimately the issuing bank. As a result, the payments architecture needs connectivity to the merchant’s payments providers to facilitate this transaction.
Merchants have two options for acquirer connectivity:
- Direct Connection. Directly connecting to a provider’s front end authorization system can reduce cost (by not using a gateway to connect and paying its fees), but may require more engineering resources to maintain, as the merchant is responsible for coding to any changes that the provider front end requires.
- Gateway. A gateway can be useful for merchants that need to connect to multiple acquirers, as the gateway is responsible for maintaining the direct connections with multiple acquirers.
Routing Logic
Some merchants want to have control over how each transaction is routed to its providers. For instance, they may send certain debit transactions to the debit networks for cost purposes. They may design for resilience and the ability to failover seamlessly to another provider in the event of an outage or connectivity issue. Merchants can choose to build this themselves, but some gateways can provide intelligent routing on their behalf.
Retry Logic
Merchants that have recurring payments needs, e.g. billers and subscription providers, often have business logic that dictates when and how a transaction is retried if it fails on the initial approval request. Merchants may build this logic themselves, or may use a tightly integrated third party to provide this retry logic.
Connections to Fraud Management Tools
A merchant has multiple options when incorporating fraud tools into their payments environment.
- Acquirer Fraud Tools. Many acquirers offer their own fraud prevention and risk management tools. They may be built in-house by the acquirer or be a white-labeled solution from a third party fraud tool provider. Use of an acquirer’s fraud tool may be sufficient for a low risk merchant with a single provider. However, we often see merchants with both single and multiple acquirers choosing to add additional fraud tools, especially for transactions in the remote domain, card not present context.
- Gateway Fraud Tools. Merchants that use a gateway to connect to multiple acquirers may have access to a gateway’s fraud tool solution. Again, this may be sufficient for some merchants, while others may seek point solutions.
- Third Party Fraud Tools. These point solutions are solely focused on preventing fraud and managing risk, and may also include workflow management for operations teams. Given their position in the transaction flow, tight integration into the payments environment is critical.
Data Ingestion and Storage
As we discuss in our post on Reporting and Analytics, managing payments operations requires the ability to develop timely reports and real time dashboards from the data provided by the merchant’s payments providers. Without this capability, the merchant has little ability to monitor KPIs and the health of its payments operations. A modern payments environment will ingest, translate, normalize, and store data sent from multiple providers. We typically recommend merchants build this operational capability in-house, but some merchants do choose to use third parties to store and manage their payments data.
This data ingestion also needs to be tightly integrated with Accounting and Reconciliation teams and services, as the payments data from providers should be reconciled against internal data to generate exceptions when the data does not match.
Token Management
Merchants that use their acquirer, gateway, or a third party token provider to store card credentials also need a place to store and manage the associated tokens generated by these providers. Tokens are used to identify each transaction without direct reference, in card not present environments, to the card on file. Storage and management of a merchant’s token database are key components of the merchant’s payments infrastructure.
Account Updater Logic
Merchants with cards on file can use services such as Visa’s Account Updater (typically offered through their acquirer or third party token provider) to maintain up to date card credential information. Depending on whether the merchant uses a batch or real-time version of Account Updater, there is typically business logic that dictates which cards are sent for an update, and when. This logic is integrated with the internal token management service.
Conclusion
As the global payments ecosystem continues to rapidly evolve, maintaining a flexible payments environment will be paramount to merchants. Modern platforms with developer-friendly APIs are well positioned to capture the high growth businesses that will become tomorrow’s enterprise-level companies. Incumbent providers will need to continue modernizing their platforms and leveraging their established platform performance while they accelerate their ability to adapt more quickly to changes in the payments ecosystem and resulting merchant needs.
Do you need assistance assessing your payments environment and developing a long-term strategy for your payments architecture? We would be happy to learn more about the unique challenges your organization faces to help you navigate these trade-offs and set you up for the future. Reach out if you would like to discuss how your organization could benefit from Glenbrook’s Merchant Payments Assessment.
