Architecture

How NXOPAY is built

A ten-service architecture engineered for regulated payment infrastructure: a proprietary orchestration engine, a constraint-layer immutable ledger, multi-tenant isolation, and GCC data residency — deployed the way you need it.

Platform architecture

Ten independent services, one proprietary engine

The platform runs as a set of independent services on Kubernetes, hosted in-region. No third-party orchestration layer sits above it — at any time, by design.

01

Proprietary orchestration

The routing and decisioning engine is built in-house. No external orchestration platform is permitted above it.

02

Independent services

Ten services deploy and scale independently on Kubernetes, isolating failure and simplifying change.

03

GCC data residency

Infrastructure is hosted in-region, so data residency is a property of the architecture, not a configuration afterthought.

04

Event-driven core

Signed webhooks and an immutable delivery log span twenty-two event types, with idempotent deduplication.

05

Idempotent by design

A deterministic state machine prevents double-processing under retries and network failure.

06

Horizontal auto-scaling

Services scale independently to meet demand, against defined p99 service-level objectives.

Ledger model

An immutable financial ledger

Financial records cannot be altered, rewritten, or removed — making compliance, reconciliation, and audit provable by design. This is the asset most platforms only appreciate after a reconciliation failure.

Append-only

Records are written once. There is no code path that updates or deletes a posted entry.

Constraint-layer enforcement

Immutability is enforced by the database itself — through constraints and row-level security — not by application logic that can be bypassed.

Double-entry

Every movement balances, with attribution down to the sub-merchant level.

Seven-year retention

Audit records are retained to the regulatory minimum, queryable for the full period.

Security model

Security enforced in the architecture

Security is gated into every stage of delivery and enforced at the data layer — not bolted on afterwards.

Zero-trust access

Every human and service carries an explicit identity and permissions. No implicit trust anywhere in the system.

Card data never stored

Hosted-session tokenisation means raw card data never enters NXOPAY systems.

Row-level security

Separation of duties is enforced at the database layer, not just in application code.

Signed webhooks

HMAC-SHA256 signatures, a short replay window, and idempotent deduplication on every event.

Gated security pipeline

Secret scanning, penetration testing, PCI DSS SAQ, and OWASP coverage — non-waivable release gates.

Documented service levels

Published p99 objectives, defined recovery targets, and continuous metrics across every service.

<2.5s
Auth latency
p99 target
<60ms
Ledger write
p99 target
15min
Backup RPO
recovery point
4hr
Recovery RTO
recovery time

Service-level figures are platform engineering targets, not contractual service guarantees.

Multi-tenancy model

Multi-tenant from day one

The platform was built multi-tenant from the first line — the same codebase serves the network, co-branded programmes, and fully white-labelled enterprise installations.

01

Per-tenant isolation

Row-level security separates every tenant at the database layer, enforcing data boundaries below the application.

02

Custom domains & branding

Each tenant can run its own domain, email sender, and branded templates — down to zero third-party exposure.

03

One codebase, three models

Moving between deployment models is a configuration change, not a replatform project.

Deployment options

Three ways to deploy. One codebase.

Choose the model that fits, and change it later as a configuration — not a rebuild.

Scenario 01

Operate on our network

NXOPAY runs the network end to end. The fastest route to live — the platform handles checkout, settlement, and rewards.

  • Fastest time to live
  • Platform-managed operations
  • Operational across markets
Scenario 02

Co-branded

Bring your own acquiring relationship; NXOPAY operates the network beneath your programme, with zero change to your acquiring setup.

  • Your acquiring, unchanged
  • Co-branded experience
  • Ideal entry for banks & retailers
Scenario 03

Full white-label

Your brand only — your domain, your email sender, your templates. No NXOPAY presence anywhere in the experience.

  • Your brand, your domain
  • Zero third-party exposure
  • Negotiated enterprise terms

For technical evaluation

Detailed architecture and security documentation is available to qualified counterparties on request, under NDA.