Timeouts end in a reversal, not a mystery.
A financial response that never arrives triggers an 0400 built from the original data elements, retried three times and then queued with an alarm.
0400 · original data elements · 3 retries
T-NET Acquiring Route · TANTRA PAYGATE 3.0
The wire, handled.
Everything between the tap and the issuer: a data-driven ISO 8583 engine, a PIN that never leaves the module, a duplicate that gets the same answer twice, and a timeout that ends in a reversal rather than a phone call.
ISO 8583 · LLBC
DUKPT · HSM
Auto-reversal
Active / active
Primary bitmap
00 00 00 00 00 00 00 00
ISO 8583protocol engine
0100 → 0810message types carried
< 300 msinternal processing
150 / 300TPS sustained / peak
3currencies · USD SAR USD
The failure ledger
Every feature here exists because something went wrong first.
Switches are not bought on capability lists. They are bought by people who have already lived through one of these. So this is the list, in the words an operations lead would actually use.
The card was debited. The merchant was never paid.
A financial response times out. The reversal engine builds an 0400 from the original data elements, retries three times, then queues it and raises an alarm. A reversal that arrives with no original is answered with the agreed decline code rather than silence.
0400 · 3 retries · alarmThe customer tapped twice because the screen froze.
Duplicate detection holds a replay window keyed on message type, PAN, processing code, amount, trace number, retrieval reference and terminal. The replay returns the stored response — not a second authorisation.
replay window · stored responseAdding one scheme endpoint took a release cycle.
The field map, message-type matrix, processing codes and response codes are a configuration profile, not code. A new endpoint is a profile.
profile, not releaseSomeone found a PIN in a log file.
PIN blocks are built on the terminal under a DUKPT key derived per transaction and translated only inside the HSM. Clear PIN values never exist in the application tier and are never stored. The acquiring command set is domain-separated from issuing and ATM.
DUKPT · HSM only · domain-separatedThe merchant says we declined them. We cannot prove why.
RRN, authorisation code and STAN are generated and stored for every transaction and carried into clearing, settlement and disputes. Entity validation failures return a specific reason before any switch traffic exists.
RRN · auth code · STANA terminal took a currency it was never provisioned for.
Each terminal carries its permitted transaction currencies in its capability profile. A transaction in a currency the terminal is not provisioned for is declined at the gateway, before it reaches the switch.
capability profile · declined at the edgeThe scheme link dropped at 03:00 and nobody noticed until the branch opened.
Persistent sessions hold an active and a standby connection per endpoint across primary and DR ports, with a sign-on, an echo heartbeat every 60 seconds, three retries and automatic failover.
echo 60s · 3 retries · failoverSettlement did not balance and nobody could say where it broke.
Clearing files are generated and ingested against stored transactions, settlement positions are calculated per merchant, institution and currency, and reconciliation runs three ways across terminal, switch and scheme records.
three-way reconciliationEight things worth saying plainly
The short version.
A new endpoint is a profile.
Field map, message-type matrix, processing codes and response codes are configuration. Adding a scheme endpoint does not mean a release.
data-driven packaging · config, not code
The PIN never leaves the module.
PIN blocks are built on the terminal under DUKPT and translated only inside the HSM, by an acquiring command set separated from issuing and ATM.
DUKPT · translate in HSM · domain-separated
Every message is signed.
A message authentication code is generated and verified on every inter-switch message, under working keys wrapped by a dual-component zone master key.
MAC on every message · dual-control ZMK
Declines arrive with a reason attached.
Entity, capability and currency validation fails with a specific reason code before any switch traffic is generated. Nothing is declined anonymously.
validated before the wire · reason code returned
Two nodes. Two ports. One answer.
Active/active switch nodes with primary and DR endpoints, a standby connection per link and automatic failover on loss.
active/active · primary + DR · auto-failover
Under 300 ms is the part we own.
Internal processing is committed under 300 milliseconds, excluding core banking and scheme time. We show you which segments are ours.
< 300 ms internal · scheme time excluded
The replay gets the same answer.
A duplicate keyed on message type, PAN, processing code, amount, STAN, RRN and terminal returns the stored response rather than a second authorisation.
replay window · stored response
Latency
Where the round trip actually goes.
Most of an authorisation is spent somewhere we do not control, and pretending otherwise helps nobody. Here is the whole trip, with our segments marked.
hand-off
Illustrative segment budget for one card-present authorisation. Actual figures depend on the estate, the link and the issuer.
What the commitment means
Internal processing under 300 milliseconds, excluding core banking and scheme time. That is the part of the round trip we are accountable for, and it is the part we will hold to in a contract.
- Entity validation runs against a Redis configuration cache, refreshed on a five-minute cycle and on change
- PIN translation and MAC happen in one HSM round trip, not several
- Duplicate detection runs before the message is transmitted, not after the response
- Growth sizing is dimensioned for 150 transactions per second sustained and 300 at peak
- 99.9% availability target, excluding planned maintenance
The timeout
The two minutes that decide whether you get a phone call.
This is the sequence that matters most and gets demonstrated least. Watch it twice: once where the scheme never answers, and once where it acknowledges the reversal.
What is guaranteed and what is not
We can guarantee that a timeout produces a reversal, that the reversal carries the original data elements, that it is retried and then queued rather than dropped, and that an alarm reaches operations. We cannot guarantee the scheme answers it. Anyone who tells you otherwise is selling something.
- Financial-response timeout triggers an automatic reversal
- Reversal carries the original data elements and is retried three times
- Unacknowledged reversals are queued with an alarm, not discarded
- A reversal with no original is answered with the agreed decline code
- The original, if replayed, returns the stored response — never a second authorisation
Routing
One installation, several licensed institutions.
BIN and route tables belong to an institution, not to the box. Every record carries an institution key, and the back office is scoped to it — so a rule written for one acquirer cannot fire on another's traffic.
Its own identity
Acquirer ID, BIN and route tables, settlement identity, GL mapping, branding, users and reporting scope — per licensed entity.
An institution key on every record
Segregation is structural rather than procedural: the key is on the record and the role is scoped to the institution.
Capacity that grows
A base product licence for the installation, an institution licence per licensed entity, and a capacity licence that grows with terminals and merchants.
Config, not code
The message set is a profile you can read.
ISO 8583-1:1987 with a data-driven packaging profile: binary primary and secondary bitmaps, ASCII field bodies, and a two-byte binary length header on the TCP stream.
| MTI | Pair | Carries |
|---|---|---|
| 0100 | 0110 | Authorisation and pre-authorisation |
| 0200 | 0210 | Financial request and response |
| 0220 | 0230 | Advice and advice response |
| 0400 | 0410 | Reversal and reversal response |
| 0420 | 0430 | Core-banking-side reversal |
| 0800 | 0810 | Network management — sign-on, sign-off, echo, key exchange |
Processing codes cover purchase, purchase with cashback (the cashback portion carried in the additional-amounts field), refund within the agreed window against the original reference, balance inquiry, card and token authentication, and settlement batch. Legacy codes are normalised at the edge of the switch.
The suite
One vendor, one data model, four products.
The acquiring platform reuses the institution, user and audit model already running the issuing and ATM estate. That is why card status, terminal behaviour and switch routing never disagree.
T-NET Acquiring Route
ISO 8583 engine, scheme and CBS connectivity, HSM services, risk and AML, clearing, settlement and chargebacks — with TANTRA PAYGATE 3.0 in front of it.
My Mercho Suite 2.0
Institution, aggregator, merchant, store and terminal masters; KYC; MDR and fees; maker-checker; the merchant portal.
Smart POS 2.0
The POS application and Payment SDK, QR acceptance with device binding, Secure Point, and terminal attestation.
CARD PRIME D 3.0
Card lifecycle, onboarding and KYC, instant issuance, embossing, digital and virtual cards — the other side of the same platform.
Nine hundred milliseconds.
An authorisation is over before anyone in the shop notices it happened. The film slows one down until every hop is readable — the same trace the switch writes for itself.
- 000msTerminal presents the card. 0200 leaves the POS.
- 040msGateway: schema, MAC, velocity, duplicate check.
- 120msRoute chosen. ON-US — the issuer is us.
- 310msCore banking holds the funds. Response assembled.
- 690ms0210 back through the gateway, field 39 = 00.
- 880msReceipt prints. The clerk has already looked away.
FILM IN POST · MARKS LOCKED
Switch specificationNext step
Send us your message spec. We will send back a profile.
Your scheme endpoint, your CBS interface and your terminal mix are enough for us to come back with an ISO 8583 packaging profile, a sizing note and a certification schedule.