Payment Switch is a complex fabric in which functionality and technicality are intricately woven to provide a solid platform to deliver ever increasing different type of payment services with high throughput & resilience.

From 10000 Feet view, it might seem that “PS” is a generic platform used to transform and route different kind-off payment messages for authorization. But as we climb down the chain we can see different payment services, multiple components and complex technical components and frameworks to support payment services.

In the above image, I tried to capture few properties/components of a switch.  Layers at higher level are dependent on the ones at lower level.

Payment Services: Gone are the days when switch was only supposed to process Credit Card (CC)/ Debit Card (DC) authorization transactions.

• Loyalty / Prepaid: As a part of authorization transaction or individual transaction, based on loyalty/prepaid service switch should be able to perform desired functionality like amount load, point addition etc.
• Wallet: Wallets are becoming intricate part of mobile based financial transactions and they are being used for multiple purposes starting from remittance to bill payments to service recharges etc.
• Value Added Services (VAS): Services like insurance, health, premium payment, recharges, immediate payments.
• Token Vault: Secure and compliant token vault services for safe-keeping of sensitive data like card number.
• Merchant Services: Merchant onboarding (+management), charges & billing, batch closures.

Supporting Services: To support different payment services, additional services are required.

• Fraud Detection: Checking and identifying fraudulent transactions and raising RED flag based on configured parameters.
• Device Management System: Integration and handling of both POS and ATMs. handling).
• Key Management: HSM integration into Switch at required functional points. Key handling, key rotations, key sharing etc.
• Reconciliation and Settlement: Recon and settlement is important functionality for both end-points of switch – Processor & Merchant
• Dynamic Currency Conversion: To support foreign currency transactions, currency conversion based on exchange rates is a required feature.

Moving further down, service components are defined. Payment Services consume service components directly or via Supporting services. Above mentioned abstract layering is just an “VIEW” of different type of services/components.

The second aspect of switch, i.e., technology is equally important otherwise it becomes next to impossible to provide payment services in a consistent manner.

From architecture and design view point Payment Switch has to be high performance system besides highly resilient and available. This aspect makes PS technically challenging.

To support transactions with TPS of 10000 and more and provide high-availability at different level of system is not a simple task. Lot of architecture design patterns, integration methodologies are available to solve the NFR (non-functional requirements) of switch.

Load and Performance: High end switch has to handle simultaneous tens of thousands of ATMs and POS device and they have to ensure zero or less degradation in performance. Earlier ATMs, used to maintain connection with switch for long durations, which is again a huge bottleneck.

With large number of transactions, performance becomes a major sufferer: from application server to Databases - less memory, less CPU and less disk space.

Solution comes primarily in 2 variations:

• Combination of hardware and software like HP Non Stop, Stratus. TCO becomes significantly high in this case.
• Scale out Architecture: Using commodity hardware and software. Depending on load requirement, server farm can be scaled out.

High Availability: Being a “financially” sensitive system, any downtime (crash) of switch results in financial loss. HA needs to be maintained from multiple perspectives: Inside Data Centre, Primary DC -BackUp DC, Primary DC – Primary DC.

Factors like latency (both inside DC & between DCs), scheduled/non-scheduled maintenance time, patch deployment, self-healing etc. matters lot in production environments.

Resilience: The expected (both functional and technical) behavior of switch under varied conditions & zero transaction loss in any case. Especially, behavior under crash & no response from components (component is live but not responding).

Tendency towards conversion for Spaghetti Architecture: Mostly payment systems have to integrate with multiple external systems for data posting, validation, authentication, data reporting etc. Its results in supporting various formats, transmission protocols, communication protocols and most importantly multiple invocation points inside transaction life-cycle.

Finally, the architecture converts into Spaghetti architecture, which in long run is a BIG NO and DANGEROUS.

In this blog, I tried to bring some aspects of Payment Switch from both functional and technology perspective. In the next blog, I will discuss the solution….Till then.