Architecture
The control layer around approved partner rails
NXOPAY is designed to preserve authoritative records, lifecycle state, reconciliation evidence, merchant-program rules, and operating accountability across complex commerce programs.
From execution to control
Payment execution is only one part of commerce infrastructure
Enterprise commerce programs require lifecycle accountability beyond authorization and settlement. NXOPAY delivers deterministic state tracking across issuance, redemption, refund, dispute, reconciliation, settlement, and evidence workflows.
Design intent
NXOPAY is designed around that broader lifecycle — the authoritative record, settlement state, and audit evidence — while approved partner rails remain the execution channel beneath it.
Architectural layers
Four layers, one control philosophy
Program services create the commerce experience. Control services and enforcement preserve the record beneath it. Approved partner rails perform the regulated functions.
Program services
Where transactions begin.
Merchant-program services manage transaction initiation, lifecycle state, merchant rules, customer-facing flows, notification events, and operational workflows.
Control services
Where transactions become accountable.
Control services support ledgering, reconciliation, refund/dispute records, merchant compensation logic, provider-readiness state, and operating evidence.
Enforcement and audit
The record beneath every service.
Data-layer constraints, access controls, immutable records, and audit trails preserve the authoritative record beneath changing services. Transaction-state discipline is backed by typed verification and automated test coverage, so unverified financial effects are rejected rather than silently accepted.
Approved partner rails
Regulated functions stay regulated.
Licensed payment, banking, acquiring, APM, and infrastructure partners perform regulated financial functions through approved commercial and regulatory setups.
Layered enforcement
Controls live beneath the services, not inside them
Services are where change happens. Controls are where financial state is constrained, verified, and preserved. Putting the two in different layers is what makes the record authoritative.
Layer 01 — services
Program & control services
Deploy, scale, and change independently. Each service owns its own release cycle, and a failure is contained rather than shared.
SYSTEM ENFORCEMENT LAYER — NON-BYPASSABLE
The database enforces what the services cannot override
Immutability, balance, and tenant boundaries are constraints, not conventions.
- Posted entries protected by append-only ledger discipline
- Double-entry balance checks enforced at the constraint layer
- Tenant isolation enforced by row-level security at the database layer
- Application workflows designed around controlled lifecycle transitions
Ledger model
An immutable financial ledger
Deterministic ledger integrity. Posted financial records are protected by database-enforced constraints, append-only discipline, double-entry balance checks, and tenant isolation controls. Reconciliation outputs and transaction states are designed to be auditable by default.
Append-only
Posted entries are protected by append-only ledger discipline and database-enforced constraints.
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 participating-storefront level.
Structured retention
Audit records are retained to support reconciliation and dispute evidence over the program lifecycle.
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.
Card data handled through hosted flows
Card data is handled through hosted provider flows where applicable — raw card data never enters NXOPAY systems.
Append-only, double-entry discipline
Financial records are designed around append-only, double-entry discipline enforced at the data layer.
Tenant separation & access controls
Tenant separation and access controls are part of the data model, enforced below the application layer.
Idempotency & replay resistance
Webhook and transaction-state handling are designed for idempotency and replay resistance on every event.
Gated security pipeline
Secret scanning and OWASP-aligned review are non-waivable release gates, applied on every release.
Documentation under NDA
Technical documentation is available to qualified counterparties under NDA.
Service-level figures are platform engineering targets, not contractual service guarantees.
Tenant & deployment flexibility
Multi-tenant from day one
The platform is built for multi-tenant deployment from one codebase — the same codebase supports NXOPAY-operated, group-operated, co-branded, and partner-enabled models under agreed commercial and compliance terms.
Per-tenant isolation
Row-level security separates every tenant at the database layer, enforcing data boundaries below the application.
Custom domains & branding
Each tenant can run its own domain, email sender, and branded templates under agreed terms.
One codebase, three models
Moving between deployment models is a configuration change, not a replatform project. See the deployment models →
FAQ
Technical & Regulatory Architecture FAQ
How does NXOPAY support local data-residency requirements?
Data residency is treated as a deployment parameter, not a product rewrite. NXOPAY's architecture is intended to support jurisdiction-aware deployment models where transaction records and operating data can remain within the approved hosting, provider, and regulatory setup for the relevant market.
Does NXOPAY process or store raw cardholder data?
NXOPAY is designed around hosted provider payment flows. Sensitive card authentication and payment payloads are handled by licensed or approved payment partners. NXOPAY focuses on transaction state, ledger records, reconciliation, lifecycle evidence, and operating workflows.
How are tenant boundaries protected?
Tenant isolation is enforced by row-level security at the database layer, including row-level tenant isolation patterns where applicable. Database-level controls support tenant isolation, ledger integrity, and auditability.
Technical materials
Detailed architecture, security, and implementation materials are available to qualified counterparties under NDA.