ACQUIRING ISO 8583 MODULE
0200Financial Transaction Request
F02PAN4111 11•• •••• 1111
F03Proc. Code000000 (Purchase)
F04Amount000000180000 (₹180.00)
F07Timestamp0626091244
F11File STAN482917
F22POS Entry051 (Chip+PIN)
F41Terminal IDTID:88041239
F42Merchant IDMID:40281930
F49Currency356 (INR)
⚡ ROUTING DECISION3.1ms
POS Terminal Visa Host · Primary
Rule: BIN 411111 · Txn ID · Scheme Visa · Fallback: Standout host
00APPROVEDAuth Code: 482917
Response: 71ms
4,381
TPS · now
99.8%
approval
78ms
avg RTT

Switch Performance

Built for the Numbers That Actually Matter

A payment switch is not judged on features. It is judged on throughput, latency, availability, and accuracy. Here is where DigiPay.Guru's switch stands.

10K+

TPS Peak Throughput

<80ms

End-to-End Auth Latency

99.999%

Switch Uptime SLA

50+

Host Integrations

128

ISO 8583 Data Elements

// WHAT_IS_AN_ACQUIRING_SWITCH

The Switchboard No One Sees. The One Everything Depends On.

An acquiring switch is the real-time message router that sits between your terminals and the card networks. Every payment starts and ends here.

When a cardholder taps their Visa card at a POS terminal, a payment message is generated — formatted in ISO 8583, the international standard for financial transaction messaging. That message travels to the acquiring switch, which parses every data element, validates the format, identifies the card scheme and BIN range, applies routing rules to select the appropriate host, and forwards the authorization request — all within milliseconds.

The host responds. The switch receives the response, maps it back to the original request, records the transaction in the authorization log, and returns the response to the terminal. The cardholder sees "Approved" in under a second. That entire sequence — parse, route, authorize, respond — is what the acquiring switch does. Billions of times a day, across every payment network on earth.

Switch Routing · Live● online
POS / SoftPOS / mPOS Terminal
ISO 8583 0200 · Chip+PIN request
Sender
Acquiring Switch Platform
Parse, route, authorize, respond
Core Engine
Card Scheme / Issuer Host
VisaNet / Mastercard MIP / RuPay NPCI
Authorizer
Terminal receives authorization
Response code 00 · Approved
Complete

Six Layers. One Platform. Every Transaction Covered.

The Acquiring Switch Platform is not a single component — it is six tightly integrated modules that together cover the complete lifecycle of a payment authorization message.

$ process --protocol.iso8583 --mti=0200

ISO 8583 Message Processing Engine

ISO 8583 is the language of card payments — an international standard that defines exactly how financial transaction messages are structured, encoded, and transmitted between terminals, switches, and hosts. Every authorization request, response, reversal, and advice flows as an ISO 8583 message. DigiPay.Guru's message processing engine handles the complete ISO 8583 message lifecycle.

PARSEFull 128-element ISO 8583 bitmap parsing and validation
MTIAll MTI classes: 0200/0210, 0400/0410, 0800/0810 and reversals
PROTOTCP/IP, TLS 1.2/1.3, HTTP/2, and VISA BASE I / MASTER I transports
VALIDField-level format, length, and data type enforcement on ingress
DEDUPDuplicate message detection via STAN + Terminal + Terminal ID
LOGFull message trace log with field-level diff on retransmissions
iso8583 · message · liveVALID
F02PAN4111 11•••• •••• 1111
F03Proc000000
F04Amount₹10,083.30
F07Date0626 09:12:44
F11STAN482917
F22POS Entry401
F25POS Cond.00891229
F37Ref No.48711930
F41Terminal48T16918
F49Currency356 · INR
✓ All 47 mandatory fields present · Bitmap: 7234380063800030

$ route--bin=411111 --scheme=visa --fallback=enabled

Intelligent Transaction Routing Engine

Routing is where the acquiring switch earns its keep. The decision of which host to send an authorization request to — and in what order — determines your authorization rate, your interchange qualification, your latency, and your cost per transaction. An intelligent routing engine uses real-time data to make the best decision for every transaction individually.

BINBIN-based routing: maps card ranges to specific host connections
SCHMScheme-based routing: Visa, Mastercard, RuPay, Amex, Diners routed independently
MCCMCC-based routing: different hosts for different merchant category codes
FALLBConfigurable fallback chain: primary → secondary → tertiary host
LCLeast-cost routing to minimize interchange and scheme fees
LBLLoad balancing with real-time host health weighting
NOCODNo-code routing rule builder — ops teams configure without engineering
auth-request · decision-live · LiveROUTED
BIN
411111
Card Type
Credit · Domestic
MCC
5661 · Shoe Stores
Amount
₹12,000
Channel
POS · Chip+PIN
Rule Match
BIN-VISA-DOM-001
Primary Host
Visa India · HST-01ONLINE
Fallback 1
Visa India · HST-02ONLINE TOP
Fallback 2
Visa SingaporeONLINE
Routing
Least Cost
Latency
<7.1ms
Primary host selected · LCR rule applied · Fallback armed

$ authorize --mti=0200 --host=visa-hst-01 --timeout=5000ms

Real-Time Authorization & Response Handling

Authorization is the moment of truth in every payment. The acquiring switch sends a 0200 Authorization Request to the card host, waits for a 0210 Authorization Response, and must handle every possible outcome — approved, declined, referral, timeout, or host unavailability — correctly, completely, and in real time.

AUTHFull 0200/0210 request-response lifecycle with timeout management
APRVPartial approval handling — terminal informed of approved amount
RESPResponse code normalization: host codes → standardized acquirer codes
TMOUTConfigurable timeout per host with automatic reversal on expiry
SAFESmart retry logic: duplicate detect on prevents double-authorization
RVRSLAutomatic 0400 reversal generation on host timeout or system failure
ADVSE0220 completion advice for offline and stand-in transactions
auth-log · transaction-flow · #0041APPROVED
STAN
482917
Sent Time
09:12:44.001
Host
Visa HST-01
Timeout
5,000ms (configured)
Received
09:12:44.079
RT
78ms
Rsp Status
00 · #ApprovedSUCCESS
Auth Code
482917
Approved Amt
+₹10,000.00
BIN Status
XY6918
Resp sent to TID
09:12:44.082
Total RTT
81ms end-to-end
✓ Auth complete · No reversal needed · Logged to settlement queue

$ connect--host=visa-india --protocol=visanet --tls=1.3

Host Integrations & Connectivity Framework

A payment acquiring switch is only as capable as its host connections. Every card scheme — Visa, Mastercard, RuPay, Amex, Diners — has its own proprietary host connectivity protocol, message format extensions, and certification requirements. Building and maintaining these integrations in-house is one of the most time-consuming and technically demanding tasks in payment infrastructure.

DigiPay.Guru's Host Integration Framework provides pre-built, certified connectors for all major card scheme hosts and payment networks. The framework also manages connection pooling, keep-alive signalling, echo test scheduling, and automatic reconnection.

HOSTPre-built connectors: Visa (BASE I), Mastercard (MIP), RuPay (NPCO), Amex, Diners
DILTPer-host bank connectivity: custom ISO 8583 dialect support per host
POOLPersistent connection pooling — no per-transaction TCP handshake overhead
ECHOAutomated echo test (0800/0810) with configurable intervals
FAILAutomated failover to secondary host on primary connection loss
CNFIGNew host integrations via configuration — no code deployment required
CERTPre-certified for Visa and Mastercard host connectivity standards
host_connections · status · Live6 ACTIVE
Visa VISANet
VISA-HST-01
ONLINE TOP
Visa RDI-BK
VISA-BK1-02
ONLINE
MC MCY Int'l
MC-INT-01
ONLINE TOP
RuPay
NPCI Primary
ONLINE
Amex
Global Network · TLS
ONLINE TOP
NCFD Bank
Custom TSO 84S1 Host
STANDBY
Echo TestsAll passing · 30s interval
Pool Size32 connections · 4 per host
Last Failover14 days ago · auto-recovered
5/6 hosts online · Auto-failover armed · Pool healthy

$ translate --from=iso8583 --to=iso20022 --schema=pain.001

ISO 20022 — The Next Standard. Ready Now.

ISO 20022 is the new global standard for financial messaging — richer, more structured, and more interoperable than ISO 8583. Visa, Mastercard, SWIFT, and central banks worldwide are actively migrating to ISO 20022. For acquirers, this means the message format their switch must support is changing — and the window to prepare is closing.

DigiPay.Guru's Acquiring Switch Platform is ISO 20022 ready. The translation capability is the bridge that makes ISO 20022 migration manageable. You do not need to replace terminals or rewrite downstream systems simultaneously.

ISO22ISO 20022 schemes: pacs.002, pacs.008, pain.001, camt.056
TRNSLReal-time ISO 8583 → ISO 20022 translation with full field mapping
ISO83ISO 20022 → ISO 8583 reverse translation for legacy host connectivity
VALIDXML schema validation on all ISO 20022 messages before forwarding
PHSEDPhased migration support: run ISO 8583 and ISO 20022 in parallel
SWIFTSWIFT MX message compatibility for cross-border acquiring
iso20022-translator · pacs.001 · convertTRANSLATED
InputISO 8583 · 0200
OutputISO 20022 · pacs.002
Schemepacs.001.001.09
Document:
<CdtTrfTxInf>
<Amt> 482917 Pm1s
<Amt> ₹1003.20 Amt
<Ccy> INR Dy
<Value Date> 2026-06 Telno
</CdtTrfTxInf>
✓ Field mapping: 47 elements translated · Validation passed · 3.2ms

$ monitor --dashboard=ops --alerts=realtime --tps=live

Switch Operations, Monitoring & Management

A payment switch that processes thousands of transactions per second must also be observable, manageable, and self-healing. When an anomaly occurs — a host going offline, an approval rate dropping, a processing latency spike — your operations team needs to know within seconds, not minutes.

The Switch Operations Console provides real-time visibility into every dimension of switch performance. Beyond monitoring, the console provides operational controls: enable or disable routing rules, bring hosts in or out of rotation, trigger manual echo tests, replay failed transactions from the exception queue, and manage BIN table updates — all without touching the underlying switch configuration files.

OPSLive TPS dashboard with per-host and per-BIN breakdown
APVLApproval rate monitoring with configurable alert thresholds
LATLatency percentiles: p50, p95, p99 per host and message type
ALRTReal-time alerts via webhook, email, SMS, or PagerDuty
CTRLNo-downtime routing rule changes via console or API
BINBIN table management: upload, validate, and activate new BIN ranges
AUDTImmutable transaction audit log with full message replay
ops-console · switch-ops · LiveNOMINAL
TPS (now)
4,381NORMAL
TPS (peak)
9,848 today
Approval Rate
99.8%TARGET
Latency p50
49ms
Latency p95
148ms
Latency p99
211ms
Threat Score
0.03%LOW
Reversals
14 today
Exceptions
021:48
All tests nominal · 0 alerts firing · Auto-scaling active

// PERFORMANCE_SPECS

Built for the Numbers That Actually Matter.

A payment switch is not judged on features. It is judged on throughput, latency, availability, and accuracy. Here is where DigiPay.Guru's switch stands.

10K+
Transactions Per Second

Peak throughput in production deployments. Horizontal scaling allows capacity expansion without switch downtime or reconfiguration.

<80ms
End-to-End Authorization

Median authorization latency from terminal message receipt to response delivery. p99 latency under 250ms even at peak load.

99.999%
Platform Availability SLA

Five-nines uptime with active-active redundancy, geographic failover, and zero-downtime deployment for software updates.

100%
Message Audit Coverage

Every message entering or leaving the switch is logged in an immutable, tamper-evident audit trail. Zero message loss on system failure.

// CONNECTED_PLATFORM

The Switch Is the Core. The Platform Is What Surrounds It.

Every authorized transaction feeds downstream systems. The Acquiring Switch connects natively to the DigiPay.Guru platform — no middleware, no data pipelines, no integration projects.

// DOWNSTREAM

Merchant Acquiring Platform

Authorized transactions from the switch flow directly into the Merchant Acquiring Platform for clearing, settlement queuing, and financial reporting. One connected system.

Learn more
// DOWNSTREAM

Merchant Settlement System

Every approved 0210 response creates a settlement obligation. The switch logs this to the Settlement Engine in real time — MDR is calculated and the merchant's payout is queued automatically.

Learn more
// CONFIG SOURCE

Merchant Management System

Routing rules and BIN-to-MID mappings are read from the MMS at runtime. When a merchant's profile changes, the switch picks up the updated rules within seconds — no restart required.

Learn more

Frequently asked questions

A payment gateway is an API-based service that receives payment requests from eCommerce or app-based merchants and forwards them for processing. It typically operates over HTTPS and works with card-not-present transactions. An acquiring switch is a lower-level, real-time message processing engine that operates at the ISO 8583 protocol level — handling card-present transactions from POS terminals, parsing raw financial messages, managing host connections at the socket level, and processing thousands of transactions per second with sub-100ms latency. Most acquiring operations need both: a gateway for digital channels and a switch for card-present terminal transactions.

The platform supports ISO 8583:1987, ISO 8583:1993, and ISO 8583:2003, as well as proprietary extensions used by Visa (BASE I), Mastercard (MIP), NPCI (RuPay/NFS), and major bank hosts. Supported message types include: 0100/0110 (authorization request/response), 0200/0210 (financial transaction request/response), 0220/0230 (financial transaction advice/acknowledgement), 0400/0410 (reversal request/response), 0420/0430 (reversal advice), 0800/0810 (network management request/response — echo tests, sign-on/sign-off), and 0900/0910 (reconciliation). All 128 data elements in the primary and secondary bitmap are supported.

Each routing rule defines a primary host and an ordered fallback chain. When the switch sends an authorization request to the primary host and receives no response within the configured timeout (typically 3–5 seconds), it triggers the fallback sequence. The engine generates a 0400 reversal for the timed-out request, then retransmits the original 0200 to the first fallback host. If the fallback also times out, it cascades to the next host in the chain. The duplicate detection mechanism ensures that even if the primary host processes the request after the timeout (a 'delayed response'), the switch will not create a duplicate authorization. All fallback events are logged with timing details for analysis.

No terminal changes are required. The ISO 20022 translation layer sits inside the switch and operates transparently. Your POS terminals continue to send ISO 8583 messages exactly as they do today. The switch receives the ISO 8583 message, parses it, and — where the destination host has migrated to ISO 20022 — translates the message in real time to the appropriate ISO 20022 schema before forwarding. Responses from the ISO 20022 host are translated back to ISO 8583 format before delivery to the terminal. This means your terminal estate and your host connections can migrate to ISO 20022 on completely independent timelines.

The switch is designed for horizontal scaling and has been deployed at 10,000+ TPS peak throughput in production environments. Median (p50) end-to-end authorization latency — from terminal message receipt to response delivery — is under 80ms. The p95 latency is under 150ms and p99 under 250ms at peak load. The switch itself contributes less than 5ms of internal processing latency per transaction; the remainder is network round-trip time to the card host. Platform availability SLA is 99.999% (five nines), supported by active-active redundancy and geographic failover.

Yes. Both new host connections and BIN table updates are applied without switch restart or service interruption. New host configurations are loaded via the operations console and take effect immediately — the switch begins routing to the new host as soon as the connection is established and the echo test passes. BIN table updates (for new card ranges or scheme changes) are uploaded via the console or API, validated against the existing BIN table for conflicts, and activated with a single click. The switch switches to the updated BIN table atomically — no transaction is partially routed during the update.

ready_to_deploy

Your Acquiring Switch. Production-Ready. In Weeks.

Most banks and processors spend 12–18 months building switch infrastructure. DigiPay.Guru deploys it in 6–8 weeks — certified, integrated, and operating at scale from day one.

See the Settlement Engine Live
Section Page CTA

Read our insightful blogs!

Stay updated with the latest trends and innovations in finTech with our insightful blogs.