Written By- Nishant Ranjan

Payments switch is a complex fabric of functionality and technology, intricately woven to provide a solid platform. With the intent to deliver high throughput & resilience to the ever-changing field of payments services.

From a bird’s eye view, it might seem as if payments switch is a generic platform used to transform and route different kinds of payments messages for authorization. But when we take a closer look, we realize the complexity of the varied components and frameworks that are used to support the payments system.

The above representation (“Switch Architecture”) captures a few properties/components of a typical payments gateway switch.  Layers at the top are dependent on the subsequent layers below.

Payments Services: Gone are the days when switch was only supposed to process Credit Card (CC)/ Debit Card (DC) transactions authorisation. They are expected to do a lot more today:

• Loyalty / Prepaid: As a part of an authorization transaction or individual transaction based on loyalty/prepaid services, the switch should be able to perform the desired functionality like the amount top up and loyalty point accrual
• Wallet: Wallets have become an integral part of mobile based financial transactions and they are being used for varied purposes such as remittance, bill payments and service payments
• Value Added Services (VAS): Services like insurance, health, premium payments, recharges and immediate payments are growing day by day
• Token Vault: Secure and compliant token vault services for safe-keeping of sensitive data is of great importance
• Merchant Services: Merchant functionality includes on-boarding, batch closures and charges & billing

Support Services: The need to support various financial and non-financial services:

• Fraud Detection: Ability to integrate with a fraud and risk management system to identify fraudulent transactions in real time or near real time and raising a red flag based on configured parameters
• Device Management System: Integrating and handling of MPOS, POS and ATMs
• Key Management: HSM integration with the switch for key handling, key rotation and key sharing
• Reconciliation and Settlement: Recon and settlement is important functionality in both processor & merchant side of the switch
• Dynamic Currency Conversion: To support foreign currency transactions, currency conversion based on exchange rates is a required feature

Moving further down in the “Switch Architecture”, the service components are defined. Payments services consume service components directly or via supporting services. Above mentioned abstract layering is just an overview of the different types of services/components.

The technology aspect of the switch is equally important, without which it becomes next to impossible to provide payments services in a consistent manner.

From an architecture and design point of view the payments switch should be a high-performance, resilient and highly available system while retaining flexibility. The payments switch design needs to address the above challenges.

To support transactions with TPS (transactions per second) above 10,000 and to provide high-availability at different levels of the system is not an easy task. Having said that, many architectural design patterns and integration methodologies are available to solve the NFR (non-functional requirements) of the switch.

Load and Performance: A high end switch must be capable of handling tens of thousands of ATMs and POS devices without compromising on performance. The ATMs of the past, maintain connection with switch for long durations and this is a major bottleneck

With increasing number of transactions, the performance takes a hit: from application server to databases – leaving the system with reduced memory, CPU and disk space.

Solution comes primarily in 2 variations:

• Combination of hardware and software like “HP Non-Stop” and “Stratus” respectively. TCO becomes significantly high in this case
• Scale out architecture: Using commodity hardware and software, server farm can be scaled out as per the load requirement

High Availability: Being a “financially” sensitive system, any downtime (crash) of the switch results in a monetary loss. High availability needs to be maintained across multiple data centers.

Factors like latency (both within the DC and between DCs), scheduled/unscheduled maintenance time, patch deployment, self-healing etc. matters a lot in production.

Resilience: The default expectation from both functional and technical perspective, given the varied condition would be zero transaction loss.

Complexities of a Spaghetti Architecture: Most payments systems have been integrated with multiple external systems for data posting, validation, authentication, data reporting etc. It results in supporting various formats, transmission and communication protocols, most importantly multiple invocation points within the transaction life-cycle. Finally, the architecture evolves into a Spaghetti architecture, which in the long run leads to maintenance and support issues at a point of no return.

Thus, it is important for financial institutions to actively evaluate and identify products which have flexible and configurable design fundamentals, building the foundation for future proof 21^st century payments systems.