Payment Switch Architecture: What You Actually Need vs What Vendors Want to Sell You
Category: ISO8583 Switch Target reader: CTO, Tech Architect, Payments Consultant Keywords: payment switch architecture, ISO8583 switch requirements, payment routing software, card scheme switch CTO guide, ISO8583 switch vs custom
If you have spent any time evaluating payment switch solutions, you have probably encountered a pattern: the vendor demo starts with a routing diagram, moves quickly to a feature matrix that covers two slides, and then expands into capabilities that have nothing to do with why you opened the conversation in the first place. Fraud scoring engines. Loyalty point management. Merchant portal analytics. Token lifecycle management. A proprietary cloud platform that the switch requires to function.
By the end of the demo, the original question — how do I route card transactions between my transaction sources and my acquirers reliably — has been buried under a product vision that the vendor has been building toward for ten years and that you would need eighteen months and a dedicated implementation team to deploy.
This article is a reset. It defines what a payment switch actually needs to do to serve the routing function you need, separates those requirements from the features that add cost and complexity without adding value to your specific use case, and gives you a framework for evaluating switch options — including the option of a focused, deployable product like neaPay — against your actual requirements rather than against a vendor's product roadmap.
Starting From First Principles: What a Switch Must Do
A payment switch exists to solve a specific problem: a transaction arrives from a source, and it needs to go to the right destination. Everything a switch must do flows from that problem.
Receive inbound transactions. The switch must accept ISO8583 transaction messages from one or more inbound sources — applications, terminal management systems, payment channels, or other switches. This means maintaining inbound connections, reading ISO8583 messages correctly from those connections, and handling the connection-level concerns of keep-alive, reconnection, and message framing. The switch must do this reliably at whatever transaction volume your environment requires, without dropping messages or introducing latency that affects authorization response times.
Make a routing decision. Given an inbound transaction, the switch must evaluate it against a defined set of rules and determine the correct outbound destination. The routing decision must be correct — the right acquirer for the right transaction every time — and fast — routing decisions add to the end-to-end authorization latency, so they must be made in microseconds, not milliseconds.
Forward to the destination and return the response. The switch must maintain outbound connections to one or more acquirers or processing hosts, send the routed transaction over the correct connection, receive the response, and return it to the originating source. This includes managing the persistent TCP connections to each acquirer, handling echo messages and keep-alive logic, correlating responses to the correct originating request, and handling timeout and failover scenarios when a destination is unavailable.
Log every transaction. Every message the switch handles must be logged with sufficient detail to support reconciliation, dispute resolution, and regulatory audit. The log must capture the inbound request, the routing decision, the outbound message, the response, and any exception events. Logging must be reliable under load and structured for downstream use.
That is the complete functional specification of a payment switch doing its core job. Four capabilities. Everything else is optional, depending on your specific environment and requirements.
The Capabilities That Are Sometimes Needed But Not Always
Beyond the four core capabilities, there are a set of functions that legitimately belong in the switch layer for some organizations and do not belong there for others. These are worth understanding clearly so you can evaluate them against your specific requirements rather than assuming they are either universally necessary or universally superfluous.
Protocol conversion. If your inbound sources and your outbound acquirers speak different ISO8583 dialects — different field definitions, different encoding rules, different message type structures — the switch can perform the translation between them. This is genuinely useful when you have a mix of legacy and modern sources, or when different acquirers use different scheme variants. It is not necessary if all your connections speak compatible dialects and no translation is required.
Load balancing. If you have multiple connections to the same acquirer — for volume or redundancy — the switch can distribute transactions across those connections according to a defined algorithm: round-robin, least-connections, or weighted distribution. This is necessary at high transaction volumes where a single TCP connection to an acquirer becomes a bottleneck, and unnecessary at lower volumes where a single connection is sufficient.
Message transformation. Beyond dialect conversion, some environments require field-level transformation: adding fields required by a specific acquirer that are not present in the inbound message, removing fields an acquirer does not accept, reformatting field values to match acquirer-specific requirements. This is a legitimate switch function in environments with heterogeneous acquirer requirements and inbound sources that cannot be modified to meet each acquirer's specific field expectations.
Settlement file generation. Some switch deployments include generation of settlement files — end-of-day transaction summaries in the format required by each acquirer for settlement processing. This is a useful function when the switch is the system of record for transaction data and there is no downstream system that already handles settlement file generation.
Key management for encryption. When transactions passing through the switch include sensitive data — PANs, PIN blocks — that must be encrypted and decrypted as part of the routing flow, the switch may need to participate in key management: maintaining encryption keys for each connection, performing PIN block translation between key zones when routing from one encryption domain to another. This is a specialized requirement relevant to specific architectures, not a universal switch requirement.
Each of these capabilities belongs in the switch layer when your environment needs it and should be evaluated on that basis — not assumed to be required because a vendor includes it in their product.
The Capabilities That Do Not Belong in the Switch Layer
This is where vendor product roadmaps and actual switch requirements diverge most significantly.
Fraud scoring and risk management. Fraud detection requires access to cardholder history, behavioral patterns, device fingerprints, velocity checks across time windows, and a model that is continuously updated based on observed fraud patterns. This is a data-intensive, model-driven capability that belongs in a specialized fraud management system — not in a routing switch. A switch that includes a fraud engine is a switch that is trying to be two products simultaneously, and the fraud engine inside it will almost always be less capable than a dedicated fraud management platform. More importantly, you are paying for it whether you use it or not.
Loyalty and rewards management. Points accumulation, tier management, rewards redemption — these are customer relationship management functions that belong in a CRM or loyalty platform, connected to your payment stack but architecturally separate from it. Their presence in a switch adds complexity to the routing layer without serving the routing function.
Merchant portal and analytics. Transaction dashboards, merchant reporting interfaces, and analytics tools are valuable, but they belong in a reporting layer that reads from a transaction data store — not in the routing switch itself. A switch that includes a merchant portal is packaging a reporting product alongside the routing product and charging for both.
Proprietary cloud platform dependency. Some switch vendors deliver their product as a service that runs on their proprietary cloud infrastructure, with the routing configuration and transaction data living on their platform rather than yours. For some organizations this is acceptable. For many — particularly banks, regulated fintechs, and organizations with data sovereignty requirements — having transaction data and routing configuration on a third-party platform creates compliance, security, and operational dependency concerns that a deployable on-premise or private-cloud product does not create.
Card issuance and lifecycle management. Card personalization, PIN management, and card lifecycle functions are issuing platform capabilities. They may be relevant to your organization, but they are not switch functions. A vendor that bundles them into a switch offering is selling you an issuing platform with a switch attached.
The pattern across all of these is the same: a vendor has built a broad payments platform over many years, and the switch is one component of that platform. Buying the switch means buying — and paying for, and operationally managing — the platform. If you need the platform, that may be the right choice. If you need the switch, it almost certainly is not.
What Over-Specified Switch Products Actually Cost You
The cost of buying more switch than you need is not just the license fee. It is the implementation complexity, the operational overhead, and the timeline impact that come with deploying a system designed for a use case larger than yours.
Implementation timeline. A switch product designed for a large bank processing environment comes with an implementation methodology to match: a discovery phase, a design phase, a build phase, a testing phase, a certification phase. Each phase involves consultants from the vendor, documentation deliverables, sign-off gates, and timeline dependencies. An implementation that could take six weeks with a focused product takes six months with a platform product — not because the routing function is harder, but because the platform has to be configured, tested, and validated across all its capabilities, not just the ones you need.
Operational complexity. A platform product that includes fraud engines, loyalty management, merchant portals, and analytics requires operational expertise across all of those components, not just the routing function. Your team needs to understand how to manage, monitor, and troubleshoot capabilities they may never actually use — or pay the vendor for managed services to do it for them.
Upgrade and dependency risk. Large platform products have complex release cycles. An upgrade to the routing engine may come bundled with an upgrade to the fraud engine, the loyalty module, and the merchant portal. Testing the upgrade requires validating all of those components, not just the routing behavior you care about. The operational risk of each upgrade is proportional to the surface area of the product, not to the specific capability you depend on.
Cost. Platform products are priced for organizations that use the platform. If you are using 20% of the platform's capabilities, you are paying for 100% of the platform's pricing. License fees, implementation fees, annual support fees, and upgrade fees are all calibrated to the platform's full scope, not to the routing function you actually need.
The Focused Switch: What It Looks Like and Why It Is Usually the Right Choice
For most organizations that need multi-acquirer routing — fintechs, banks building digital products, acquirers, payment facilitators, system integrators delivering payment projects — the routing function is what needs to work, and everything else is either handled by existing systems or is not needed at all.
A focused switch product — one that covers the four core capabilities plus the optional capabilities that are genuinely needed — has a completely different cost and complexity profile than a platform product.
Deployment is fast. A focused switch deploys as a service in your existing infrastructure: a Java process running on a Linux host, VM, or container. There is no proprietary platform to provision, no complex infrastructure dependency to satisfy. Configuration is the primary implementation activity, and configuration work is measured in days to weeks rather than months.
Operation is simple. The operational surface of a focused switch is the switch itself: connection health, routing rule performance, transaction log management, and the monitoring of inbound and outbound connections. There is no fraud engine to tune, no loyalty module to maintain, no merchant portal to support. The team that operates the switch needs to understand what the switch does, which is routing — not a broad payments platform.
Changes are fast. When a routing rule needs to change — a new acquirer is added, a BIN range is reassigned, a failover chain is updated — the change is made in configuration and takes effect without restarting the switch. There is no deployment pipeline, no regression test suite spanning capabilities you do not use, no vendor change management process to navigate.
Cost is proportional to value. A focused switch product is priced for the routing function it provides. You are not subsidizing a fraud engine you do not use or a merchant portal that duplicates a reporting capability you already have.
The neaPay ISO8583 Switch is a focused switch product. It covers the four core capabilities — inbound connection management, routing decision evaluation, outbound connection management and response handling, and transaction logging — and the optional capabilities that are commonly needed: protocol conversion between ISO8583 dialects, BIN-based and brand-based routing, failover routing with automatic reversal handling, and direct database integration for transaction persistence. It deploys on your infrastructure, runs as a standalone service, and is configured through human-readable configuration files rather than a vendor implementation methodology.
It does not include a fraud engine, a loyalty module, a merchant portal, or a proprietary cloud platform. If you need those capabilities, neaPay will tell you directly that you need a different product for them — and that the switch will integrate with whatever fraud management or analytics platform you choose, through standard interfaces.
A Framework for Evaluating Switch Options
When evaluating switch options against your requirements, a useful framework is to work through the four core capabilities and the relevant optional capabilities explicitly, and ask each vendor how their product addresses each one.
For the core capabilities, the questions are operational: how are inbound connections managed, what is the failover behavior when an inbound source disconnects, how are outbound acquirer connections monitored, what happens when an acquirer connection is lost during a transaction, how is transaction logging implemented and what is the log structure.
For the optional capabilities, the questions are applicability questions: does your environment require protocol conversion between specific dialects, does your transaction volume require load balancing across multiple acquirer connections, do your acquirers require message transformation that cannot be handled in the inbound source, do you need settlement file generation from the switch or is that handled elsewhere.
For the capabilities that do not belong in the switch layer, the question is simply whether the vendor can deploy the switch without requiring you to configure and operate those capabilities. If the answer is no — if the fraud engine or the merchant portal is mandatory infrastructure that must be deployed and configured even if you do not use it — that is a significant implementation and operational cost that should be reflected in your evaluation.
The right switch for your requirements is the one that covers your actual requirements without padding them with capabilities that serve the vendor's product vision rather than your operational needs.
The Decision in Plain Terms
You need transactions to go from the right place to the right place, reliably, at the volume and latency your environment requires, with a log of every message for reconciliation and audit. You need to be able to add acquirers and change routing rules without a development cycle. You need the switch to recover from acquirer outages automatically without operations team intervention.
That is a well-defined, achievable requirement. It does not require a fraud engine. It does not require a loyalty module. It does not require a proprietary cloud platform. It requires a switch that does the routing job well, deploys cleanly on your infrastructure, and can be operated by a team that understands your business requirements rather than a team of payments platform specialists.
Know what you need. Buy what you need. Operate what you bought.
Want to map your routing requirements to a switch configuration without a vendor sales process? neaPay engineers start from your requirements — inbound sources, acquirer connections, routing rules, failover needs — and tell you directly whether the neaPay switch covers them and what the configuration looks like. No platform demo, no feature matrix, no implementation methodology. Just a technical conversation about your specific routing problem.
