The Stakes of Payment Infrastructure
Every payment transaction involves multiple parties, regulatory obligations, and real financial risk. Unlike most software domains where bugs produce inconvenience, bugs in payment systems produce financial losses, regulatory penalties, and reputation damage that can destroy a company overnight. Building payment infrastructure demands a level of engineering rigour, security architecture, and compliance awareness that goes beyond conventional software development.
This guide is written for engineering and product teams building or evaluating payment systems in Nigeria and West Africa, where the regulatory environment, infrastructure constraints, and user behaviour create a distinctive set of requirements.
The Architecture of a Payment System
Core Components
A production-grade payment system consists of several interconnected services:
- Payment Gateway: The public-facing API that initiates and authorises payment requests. Communicates with card networks (Visa, Mastercard) and local payment schemes (NIBSS, NQR).
- Payment Processor: Executes the actual fund movement between accounts. In Nigeria, this requires integration with the Central Bank's NIP (NIBSS Instant Payment) infrastructure.
- Ledger Service: The source of truth for all account balances and transaction history. Must be append-only, immutable, and capable of point-in-time reconstruction.
- Reconciliation Engine: Automatically reconciles internal ledger positions against bank statements and payment network settlement files. Discrepancies are flagged for manual investigation.
- Fraud Detection Service: Real-time machine learning models that score each transaction for fraud risk and apply configurable rules to block, flag, or allow transactions.
- Compliance and Reporting: Automated generation of CBN regulatory reports, FIRS tax filings, and NFIU suspicious activity reports.
Double-Entry Ledger Design
The most critical engineering decision in payment systems is ledger architecture. Every movement of funds must be represented as a debit from one account and an equal credit to another. At no point should money be created or destroyed in the ledger. Implement this with database transactions that are strictly atomic — if any part of a fund movement fails, the entire transaction rolls back.
Store every ledger entry with: transaction ID, timestamp (nanosecond precision), source account, destination account, amount, currency, exchange rate if applicable, transaction reference, and the user/system that initiated the transaction. Never allow ledger entries to be updated or deleted — corrections are made via reversal transactions with a reference to the original.
Security Architecture
Encryption at Every Layer
- Transport: TLS 1.3 for all API communications. Certificate pinning for mobile SDKs.
- At rest: AES-256 encryption for all sensitive data including card numbers, account numbers, and BVN data.
- Key management: Hardware Security Modules (HSMs) for encryption key storage and cryptographic operations. Keys must never exist in application memory in plaintext.
- Tokenisation: Replace real card numbers with tokens in your systems immediately upon receipt. Store and process only tokens, never raw PANs, except in the HSM-backed tokenisation vault.
Authentication and Authorisation
All payment API endpoints require multi-factor authentication. Implement transaction signing where high-value transactions require a cryptographic signature from a hardware token or authenticator app. Role-based access control must restrict who can initiate, approve, and view transactions. Implement four-eye (dual approval) workflows for transactions above defined thresholds.
PCI DSS Compliance
If your system handles card data, PCI DSS compliance is a legal requirement enforced by card networks. PCI DSS Level 1 requires an annual audit by a Qualified Security Assessor. The controls required include network segmentation, penetration testing, intrusion detection, log management, and vulnerability scanning. Budget six to twelve months and significant engineering resources to achieve initial PCI DSS compliance.
Nigerian Regulatory Requirements
The Central Bank of Nigeria regulates all payment systems through a series of regulations and guidelines:
- CBN Regulatory Framework for Licensing Payment Service Providers: Defines licensing categories for switching companies, payment solution services, mobile money operators, and others.
- CBN Consumer Protection Regulations: Mandates response times for complaints, refund procedures, and disclosure requirements.
- NFIU AML/CFT Guidelines: Requires customer due diligence, suspicious activity reporting, and record keeping for anti-money laundering compliance.
- NDPR: Nigeria Data Protection Regulation governs how customer data is collected, stored, and processed.
Testing Payment Systems
Payment systems require testing strategies beyond standard software quality assurance. Implement: unit tests for all financial calculation functions with edge cases, integration tests against sandbox environments for all payment network integrations, chaos engineering to verify system behaviour under infrastructure failures, load testing to validate performance under peak transaction volumes, and penetration testing by certified security professionals before go-live.
Conclusion
Building payment infrastructure is among the most demanding engineering challenges in software. It requires deep expertise in distributed systems, cryptography, financial accounting, and regulatory compliance. Done right, it is a defensible competitive moat. Done poorly, it is an existential risk. Invest the time and expertise to do it right from the beginning.
