99.9% target
Excluding planned maintenance.
T-NET / Deployment
Your data centre. Your keys. Your transaction records.
On-premises, with separate UAT, production and DR environments, sharing the infrastructure baseline and the operations team with the issuing and ATM platform.
9.2 · Sizing
Indicative production footprint.
The growth scenario. Confirmed in the design workshop against declared volumes, peak transactions per second and retention.
| Node group | Qty | Specification | Zone |
|---|---|---|---|
| T-NET Acquiring Route nodes | 2 | 8 vCPU · 16 GB RAM · 200 GB — active/active | DMZ / switch zone |
| PayGate application nodes | 3 | 8 vCPU · 32 GB RAM · 300 GB | Internal |
| MyMercho Suite, Porta & Tantra AM | 2 | 4 vCPU · 16 GB RAM · 200 GB | Internal |
| Database — core & sensitive | 2 | 8 vCPU · 64 GB RAM · 1 TB SSD — primary/standby | Internal |
| Messaging & cache | 3 | 4 vCPU · 16 GB RAM · 200 GB — Kafka, Redis | Internal |
| HSM | 2 | payShield-class HA pair, plus one at DR | Security zone |
| UAT | 1 set | Approximately 50% of the production footprint | Internal |
| DR | 1 set | Mirror of production · RPO ≤ 15 min · RTO ≤ 4 h (target) | DR site |
9.4 · Availability and performance
What the platform is engineered to hold.
< 300 ms internal
For an authorisation, excluding core banking and scheme time.
150 / 300 TPS
Growth sizing dimensioned for 150 transactions per second sustained and 300 at peak.
Active / active
Horizontal scaling, active/active switch nodes with primary and DR endpoints, database standby, configuration cache fallback and automatic reversal on timeout.
4.3 · Technology baseline
What it is built on.
Node.js / TypeScript and the ISO 8583 engine
Gateway, merchant suite and attestation services in Node.js and TypeScript, with the ISO 8583 switching engine alongside them; containerised on RHEL or Ubuntu LTS. Flutter and Android for the POS application and SDKs; Next.js for the back office and merchant portal.
PostgreSQL 16, in two roles
A core configuration database for institutions, aggregators, merchants, stores, terminals and fee plans, and a separate sensitive database for transaction records. Oracle supported on request.
Kafka and Redis
Kafka for events and monitoring; Redis for the configuration cache on the authorization path, refreshed on a five-minute cycle and on change, and for sessions.
REST, gRPC and ISO 8583
REST over HTTPS with OpenAPI for channels and back office; gRPC between internal services; ISO 8583 to schemes and core banking. API reference, Postman collections and data dictionary issued as companion volumes.
Support
Twelve-month warranty, then an AMC.
All options include updates, security patches, scheme mandate updates and bug fixes.
| Option | Coverage | Sev-1 response | Sev-2 response | Channels |
|---|---|---|---|---|
| Standard | Sun–Thu 09:00–17:00 | 4 business hours | 1 business day | Ticketing, e-mail |
| Extended | Sat–Thu 08:00–20:00 | 2 hours | 8 hours | Ticketing, e-mail, phone |
| Premium 24×7 | 24 hours, all days | 1 hour | 4 hours | Ticketing, phone, escalation bridge |
Severity 1 is production down, or all POS, QR or e-commerce transactions failing. Excluded from the AMC: new features, customisation outside an active statement of work, issues caused by third-party infrastructure, terminal hardware faults or unauthorised changes, and onsite visits (available on request).
Next 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.