Multi-Scheme Routing: How to Support Visa, Mastercard, and Local Schemes Through a Single Integration Point
Category: ISO8583 Switch Target reader: CTO, Tech Architect, Payments Consultant Keywords: multi-scheme payment routing, Visa Mastercard routing switch, ISO8583 multi network, card scheme integration single point, payment scheme router
The first card scheme integration is the hardest. You learn the protocol, negotiate the acquiring relationship, navigate the certification process, and eventually get transactions flowing. By the time it is done, your team has accumulated hard-won knowledge about ISO8583 message structures, certification requirements, and the specific dialect your acquirer uses. It feels like a foundation you can build on.
Then the business decides it needs to accept Mastercard in addition to Visa. Or expand into a market where a domestic scheme — Cartes Bancaires in France, Mir in Russia, RuPay in India, UnionPay in China, iDEAL in the Netherlands, Multibanco in Portugal — is the dominant payment method and cannot be ignored. Or an enterprise client requires support for a specific card type that your current acquirer does not process.
Each new scheme looks, from a distance, like an extension of what you already built. In practice, each one is a largely independent integration: a different acquiring relationship, a different ISO8583 dialect, a different certification process, different field definitions, different message flows, and often a different set of operational requirements. The foundation you built for the first scheme is partially reusable and largely insufficient.
Multi-scheme support is not a feature you add to an existing integration. It is an architectural decision that, made correctly from the start — or corrected through the right infrastructure — determines whether your payment stack scales with your business or becomes a ceiling on it.
Why Each Scheme Is a Separate Integration Problem
The ISO8583 standard provides a common framework: message type indicators, a bitmap, and a set of numbered data elements. What it does not provide is uniformity in how those elements are used. Every card scheme and every acquiring host that processes ISO8583 messages has made its own implementation decisions within that framework, and those decisions accumulate into dialects that are similar in structure but different in the details that matter for correct message construction.
Field usage differs between schemes. Field 55 — EMV chip data — is present in virtually all modern card-present authorizations, but the specific EMV tags required inside the field 55 BER-TLV structure differ between Visa and Mastercard. Visa requires specific tags that Mastercard does not mandate, and vice versa. Field 60 — a private-use field — is used differently by different acquirers processing different schemes. Field 22 — point-of-service entry mode — uses the same structure across schemes but interprets specific bit positions differently depending on the scheme's own specification updates.
Message flows differ between schemes. Visa has specific requirements for the sequence of messages in particular transaction scenarios — partial approvals, referral responses, stand-in processing — that differ from Mastercard's requirements for the same scenarios. Domestic schemes often have entirely different message type structures for specific transaction types that do not exist in the international scheme specifications at all.
Certification requirements differ between schemes. Visa's certification process — formerly known as VisaNet Certification, now part of the Visa Certification Programme — has its own set of required test cases, test data, and certification environment procedures. Mastercard's equivalent process is separate, with its own test case library and certification team. Each domestic scheme has its own certification process, some of which are managed by the local acquiring bank rather than the scheme itself. Passing certification for one scheme does not satisfy the certification requirements of another.
Acquiring relationships differ by scheme. Some acquirers process multiple schemes but through separate connections with separate configurations — your Visa transactions go to one host address and port, your Mastercard transactions go to a different one, and the field definitions may differ between the two even though both are managed by the same acquiring bank. Some acquirers process all schemes through a single connection but with scheme-specific field requirements that vary per transaction. Some schemes, particularly domestic ones, are only accessible through locally licensed acquirers that may be completely separate from your international acquiring relationship.
The cumulative effect of these differences is that each scheme integration requires its own field mapping configuration, its own message flow implementation, its own certification preparation, and its own acquiring connection management. Doing this correctly across multiple schemes requires either a team with scheme-specific expertise for each scheme, or infrastructure that encapsulates those differences behind a common interface.
The Architectural Problem With Scheme-Per-Integration Approaches
When organizations add scheme support incrementally — integrating each new scheme as a separate project, extending an existing codebase, or building a new integration alongside the existing one — the result is a payment stack where scheme-specific logic is distributed across multiple codebases, multiple configuration files, and multiple connection managers, with no single point of governance over how transactions are routed, how scheme-specific requirements are applied, or how new schemes are added in the future.
This distributed architecture has specific failure modes that compound over time.
Routing logic becomes fragmented. Each scheme's routing rules — which transactions should go to which acquirer over which connection — are defined in scheme-specific code or configuration that is not centrally managed. When a routing requirement changes — a new BIN range, a new acquirer, a scheme-mandated routing preference — the change must be located and applied in each affected integration separately. The risk of applying a routing change in one place and missing it in another grows with each additional scheme.
Field mapping maintenance is duplicated. When a scheme updates its field specification — a new mandatory field, a changed encoding rule, an updated EMV tag requirement — the update must be applied to the field mapping logic for that scheme specifically. In a distributed codebase, identifying all the places where that scheme's field handling is implemented becomes a research project in itself. In a centrally managed configuration, it is a targeted update to a single mapping definition.
Certification coverage becomes inconsistent. As schemes update their specifications and issue new mandatory certification requirements, maintaining certification compliance across multiple independently implemented scheme integrations requires tracking each scheme's requirement updates separately and validating compliance for each one. Organizations that manage scheme integrations separately frequently discover certification gaps when a scheme's annual compliance review reveals that a requirement introduced eighteen months ago was applied to one integration but not another.
Adding a new scheme requires starting over. Each time a new scheme needs to be supported, the integration work begins from scratch: acquiring relationship negotiation, dialect analysis, field mapping implementation, certification preparation, connection management. There is no reuse of the infrastructure built for previous schemes, only reuse of the institutional knowledge accumulated by the team that built them — knowledge that is fragile, undocumented, and concentrated in specific individuals.
The alternative to this fragmented architecture is a single integration point: a switch that handles all scheme-specific complexity internally and presents a consistent interface to the application layer, regardless of which scheme a given transaction will ultimately flow through.
What Single-Point Multi-Scheme Integration Looks Like
The core value of a multi-scheme switch is that it moves scheme-specific complexity from the application layer to the infrastructure layer, where it can be managed centrally, updated in one place, and governed consistently across all schemes.
Your application sends a transaction to the switch through a single interface. It does not need to know which scheme the card belongs to, which acquirer handles that scheme, which field definitions that acquirer uses, or what message flow the scheme requires for a reversal. It sends a transaction with the card data, amount, currency, and transaction type. The switch determines the scheme from the card number, selects the appropriate acquirer connection and field mapping configuration for that scheme, constructs the correct ISO8583 message, submits it to the acquirer, and returns the response — all behind the interface that the application called.
From the application's perspective, there is one integration. From the switch's perspective, there are as many scheme-specific configurations as there are schemes to support — but those configurations are managed in the switch, not scattered across application codebases.
This architectural shift has concrete consequences for how scheme support scales with your business.
Adding a new scheme is a configuration change, not a development project. When the business decides to add support for a new domestic scheme or a new card type, the work is: obtain the acquiring relationship and the scheme's integration documentation, define the acquirer connection in the switch configuration, define the field mapping for the new scheme's dialect, define the routing rules that direct the relevant BIN ranges to the new acquirer, and test the message flows using the simulator. There is no application code to modify, no new connection manager to build, no field parsing logic to implement. The application continues to call the same interface it has always called.
Scheme specification updates are applied centrally. When Visa updates its field 55 requirements or Mastercard adds a new mandatory data element, the update is applied to the relevant scheme's field mapping configuration in the switch. Every transaction routed through that configuration benefits from the update immediately. There is no risk of the update being applied to one integration and missed in another, because there is only one place where Visa field mappings live.
Certification preparation is consistent. The switch's scheme-specific message construction is the same code path for every transaction of that scheme type. Certifying the switch against a scheme's test cases certifies the behavior for every transaction of that type, not just the transactions tested during the certification process. There is no secondary codebase with a different implementation that needs separate certification validation.
The BIN Table at the Center of Multi-Scheme Routing
Multi-scheme routing depends on the ability to determine, for any given card number, which scheme it belongs to — and therefore which acquirer connection, field mapping, and message flow should be applied to the transaction.
The primary mechanism for this determination is the Bank Identification Number: the first six to eight digits of the card number, which identify the issuing bank and, by extension, the card scheme. A BIN table is a mapping of BIN ranges to scheme identifiers and routing destinations. Given a card number, the switch looks up the BIN range it falls within, identifies the scheme, and applies the routing and field mapping configuration for that scheme.
Maintaining an accurate BIN table is an operational responsibility that is easy to underestimate. BIN ranges are not static. New BIN ranges are issued regularly as card programs are created. Existing BIN ranges are reassigned when issuers change scheme affiliations, when card programs are discontinued, or when BIN structures are expanded from six to eight digits — a transition that has been underway across the industry for several years and that requires updating BIN tables to handle both six-digit and eight-digit BIN lookups correctly.
The neaPay switch maintains a BIN table that is updated as part of the product's operational support, reducing the burden on your team to track BIN assignment changes across all supported schemes. Routing rules can be defined at the BIN range level — specific BIN ranges routed to specific acquirers — or at the scheme level — all Visa BINs to acquirer A, all Mastercard BINs to acquirer B — depending on the granularity your routing requirements need.
For schemes where BIN-based identification is insufficient — some domestic schemes issue cards that share BIN ranges with international schemes, requiring additional identification logic based on country code, card product identifier, or issuer-specific data elements — the switch's routing rules can incorporate additional matching conditions beyond the BIN range alone.
Domestic Schemes: The Integration Problem Nobody Plans For
International scheme support — Visa and Mastercard — is typically the starting point for payment integration planning because these schemes are universal and because the acquiring infrastructure for them is globally available. Domestic schemes are frequently treated as an afterthought, integrated only when a specific market expansion requires it and discovered to be significantly more complex than anticipated.
The complexity of domestic scheme integration comes from several sources.
Regulatory and licensing requirements. Many domestic schemes are operated under national payment regulations that require acquirers to be locally licensed. Accessing a domestic scheme often means establishing a relationship with a locally licensed acquirer in that market — a separate commercial negotiation, a separate technical integration, and a separate certification process from the international acquiring relationship.
Scheme-specific protocol variants. Domestic schemes frequently use ISO8583 variants that deviate significantly from the international scheme implementations. Some use entirely different field numbering conventions. Some use character encodings — EBCDIC, BCD packed fields — that are uncommon in international scheme implementations. Some have message type structures that do not exist in the ISO8583 standard at all and require custom handling.
Certification processes managed by local entities. Where Visa and Mastercard manage global certification programs through centralized teams, domestic scheme certifications are often managed by the local acquiring bank, the national payment authority, or the scheme operator directly. The certification documentation may be available only in the local language, the test environment may have limited availability, and the support response times may be longer than those of the international schemes.
Operational documentation quality varies. International scheme integration guides are comprehensive, updated regularly, and available in English. Domestic scheme integration documentation ranges from excellent to extremely sparse, and the gaps are filled by institutional knowledge held by local acquiring banks and their technical support teams rather than by published specifications.
A multi-scheme switch that has already been integrated with a given domestic scheme's dialect — that has gone through the certification process, identified the documentation gaps, and resolved the ambiguities through direct engagement with the scheme or its local acquirer — represents a significant reduction in integration effort for any organization adding that scheme for the first time. The switch's pre-built dialect profile for that scheme encapsulates everything that was learned during that process, making the experience of adding the scheme a configuration exercise rather than a discovery project.
What Your Application Does Not Need to Know
The degree to which a well-designed multi-scheme switch simplifies the application layer is worth stating explicitly, because the simplification is more complete than it might initially appear.
Your application does not need to know which scheme a card belongs to. The switch determines this from the BIN.
Your application does not need to know which acquirer handles a given scheme or BIN range. The switch applies the routing rules.
Your application does not need to construct different message formats for different schemes. The switch applies the correct field mapping for the scheme and acquirer.
Your application does not need to manage multiple acquirer connections. The switch maintains all connections and manages their health.
Your application does not need to handle scheme-specific reversal flows, partial approval logic, or referral response handling. The switch implements these flows according to each scheme's specification.
Your application does not need to be updated when a scheme changes its field requirements. The switch configuration is updated; the application interface is unchanged.
What your application does need to do is send a well-formed transaction request — card data, amount, currency, transaction type, terminal and merchant identifiers — and handle the response correctly. Those responsibilities are stable across all schemes and do not change as new schemes are added or existing scheme specifications are updated.
This is the correct division of responsibility between application logic and payment infrastructure. Application logic handles business decisions. Payment infrastructure handles payment protocol complexity. A multi-scheme switch enforces that division structurally, making it impossible for scheme-specific protocol details to leak into the application layer because the application layer has no interface through which those details could enter.
Planning for Schemes You Do Not Yet Need
One of the underappreciated benefits of adopting a multi-scheme switch early is that it makes future scheme additions nearly invisible from an application development perspective.
When your business decides to expand into a new geography, when a new card scheme becomes relevant to your customer base, or when a commercial opportunity requires support for a specific card type you do not currently handle, the response from your engineering team is a configuration project, not a development project. The application continues to call the same interface. The switch gains a new acquirer connection, a new field mapping configuration, and a new set of routing rules. Testing and certification are the primary activities, not implementation.
This is a meaningfully different position to be in than one where each new scheme requires a development engagement, a new connection manager, a new field mapping implementation, and a coordinated release that touches the application layer. The first approach scales with business growth without compounding engineering debt. The second approach turns every market expansion or commercial opportunity into a payment engineering project that competes for resources with your core product development.
The architectural decision to centralize scheme management in a switch rather than distribute it across application integrations is a decision about how your engineering capacity will be spent as your business grows. Made early, it is a straightforward infrastructure investment. Made after several schemes have already been integrated independently, it is a consolidation project that requires untangling distributed scheme logic and migrating it into a central configuration — achievable, but more complex than getting the architecture right from the start.
Ready to consolidate your scheme integrations or plan a multi-scheme architecture from scratch? neaPay engineers can review your current scheme coverage, your target markets, and your acquirer relationships, and map them to a switch configuration that handles all your schemes through a single integration point — including domestic schemes in markets you are planning to enter. Bring your current architecture and your expansion roadmap; the rest is configuration.
