muNSwitch
One platform for card and digital payment switching. Where conventional switches were built around a single protocol and bolted on digital payments afterwards, muNSwitch treats ISO 8583 card traffic and UPI/QR payments as first-class, native workloads — and runs the mirror issuer-host role on the same engine.
Three functional layers, one shared core
The acquiring and issuing engines never talk to a network directly. Both go through the same shared core, and every component is independently deployable and independently scalable.
Terminal & checkout ingress
Accepts transactions from physical terminals and the online checkout entry point, identifies the card and transaction type, and routes each one toward the correct network.
3-D Secure authentication
For online transactions, runs cardholder authentication before authorization — including handling a step-up challenge when the issuer requires one.
Authorization & persistence
One shared sequence for both entry points: record the transaction before it leaves the building, dispatch it, record the outcome, and trigger a reversal automatically if the outcome is ever ambiguous.
Routing engine
Decides which network owns a given transaction, using the card number range and transaction type, and hands it to that network's own connection and message format.
Network message translation
Converts a transaction into and out of each network's exact wire format — field layout, numeric encoding, message framing — one translator per network, added without disturbing any other network's traffic.
Direct network API adapters
For networks reachable by a modern REST API rather than a legacy socket connection, a parallel path handles authentication, request signing and response mapping over HTTPS.
Issuing listener
Accepts inbound authorization requests arriving from a card network, one connection per network, each with that network's own message format and framing.
Authorization decision service
The system that decides approve, decline or refer. The issuing side hands off the decoded transaction and encodes whatever decision comes back — momentPay Shield, or your existing host.
HSM, monitoring & config
A hardware security module protects PINs and keys, dashboards track health and volume, and each network's connection details and message format live in configuration rather than a rebuild.
Genuinely different protocols, one pipeline
| Dimension | Card present | Card not present |
|---|---|---|
| Entry point | Physical POS terminal or card reader | Hosted payment page, called from a merchant checkout |
| Message format | ISO 8583 — a fixed, bitmap-driven binary layout | JSON, defined by each network's own REST API |
| Transport | A persistent TCP socket per network, with that network's framing | HTTPS, secured with mutual TLS |
| Cardholder authentication | Chip & PIN, or signature, at the point of sale | 3-D Secure — a browser or app-based challenge |
Both entry points build the same internal transaction record and run through the same authorization, persistence and reversal pipeline.
Payment support matrix
| Payment type | Protocol | Support level | Business value |
|---|---|---|---|
| Credit / debit authorization | ISO 8583 | Full native | Process or stand behind cards on any connected scheme |
| Reversal & network management | ISO 8583 | Full native | Keeps state consistent when a message times out or a connection drops |
| UPI / QR digital payments | NPCI UPI 2.0 | Full native | Real-time digital payments alongside card traffic |
| Direct-network REST | JSON / REST | Extensible framework | A path for schemes moving from TCP to modern APIs |
| International messaging | SWIFT / ISO 20022 | On the roadmap | A path to global issuer messaging |
ISO 8583 card processing
Full EMV chip support, contactless readiness, multi-currency handling and intelligent network routing.
UPI digital payments
NPCI-certified processing, dynamic and static QR code generation, and real-time settlement.
Modern API support
RESTful APIs, GraphQL for flexible queries, WebSocket for real-time updates, webhook event notifications.
Three ways customers come to muNSwitch
Greenfield deployment
A new business sets up muNSwitch as its first switch: cloud deployment, network certifications and go-live typically inside three to four weeks.
Legacy replacement
An existing switch is analysed, muNSwitch is stood up in parallel, and traffic migrates gradually before the legacy platform is decommissioned.
Capability extension
The existing switch stays in place for what it already does well, and muNSwitch is added specifically to bring in UPI, QR or other digital protocols under one dashboard.
What evaluators ask
Not necessarily. The protocol engine's authorization step is pluggable, so muNSwitch can call momentPay's own risk engine, momentPay Shield, or your existing authorization service through a defined integration contract.
Yes. The acquirer switch, issuer bridge and protocol engine scale and deploy independently, so you can bring UPI online after card processing is already live, or the other way round.
Migration runs in parallel with your existing switch first, with transactions reconciled between both systems before any traffic is cut over, so nothing is migrated blind.
Deployment location and data residency are configurable according to the on-premise, hybrid or cloud-native deployment model you choose.
Additional nodes join the cluster and load-balance automatically, so scaling up is an infrastructure change rather than an architectural one.
Benchmark muNSwitch against your own volumes
Bring a rough profile of current volumes and peak concurrency, the networks you need, and your preferred deployment model. We will run a proof of concept with sample transactions and share load-testing results against your requirements.