The challenge
UniqPay's roadmap had a hard dependency on getting its Payment Aggregator licence from the Reserve Bank of India. The RBI's PA/PG framework (post-2022 guidelines) sets a specific bar: segregation of customer funds, auditable change control, a real reconciliation story, and security posture aligned with PCI-DSS. The team had a target review window and a payment-gateway core that needed to be production-shaped, not stitched together.
Three constraints shaped the build:
- The audit trail had to be the spine of the product, not a feature. RBI auditors don't accept "we'll add logging later." Every ledger entry, every state change, every webhook delivery had to be appended to a tamper-evident log from day one.
- PCI-DSS scope had to stay narrow. Storing PANs would have multiplied the security review surface and pushed the licence timeline by months. Tokenisation through a PCI-compliant vendor was non-negotiable.
- The ops console had to land at the same time as the payments API. A working gateway without a way for ops, risk, and finance to act on it isn't ready for real merchant traffic.
How we approached it
A full nine-person dedicated pod: six senior engineers, one QA, one security engineer, one DevOps engineer, plus a Hashorn PM. Every role is dedicated to UniqPay; no shared resources, no context-switching across clients. The PM runs the weekly cadence with UniqPay's engineering lead. The engineers work in tight pairs around the major surfaces (onboarding, payment orchestration, settlement, ops console), while security and DevOps own their respective verticals across every release.
We treated the RBI PA framework as a design input, not a compliance gate to bolt on afterwards. The first week's architecture doc explicitly mapped each PA-framework expectation to a piece of the system (audit log, idempotency, segregation, incident handling, reconciliation), so by the time we shipped the payments API, the licence evidence was a by-product of the build, not extra work.
What we shipped
Merchant onboarding and KYB. PAN, GST, bank-account verification, document vault, risk-scoring hooks, RBI-aligned audit on every state change. A merchant goes from sign-up to live test-payment in a single session.
Payment orchestration. One unified, idempotent API surface in front of UPI, cards, netbanking, and wallets. Each downstream surface has its own adapter, retry policy, and circuit breaker. Webhooks signed and delivered with at-least-once semantics. Tokenisation through a PCI-compliant vendor, so UniqPay's environment never sees raw PANs.
Settlement and reconciliation. T+1 settlement runs aligned with bank cut-offs. Bank-file ingestion, three-way reconciliation between provider, bank, and internal double-entry ledger. Mismatch alerts to ops. Chargeback and dispute flows that update the ledger correctly without breaking the audit chain.
Ops console. Single internal console for risk, finance, and support: transaction lookup, refund authorisation, dispute timeline, merchant 360. Role-based access for the operations org. OpenTelemetry traces linked directly from the console so support can see the path of a failed payment in one click.
Observability and runbooks. OpenTelemetry tracing across every payment surface, structured logs to CloudWatch, and runbooks for the top ten ops scenarios (failed UPI callback, bank-file late, reconciliation drift, etc.).
The outcome (4 months in, still ongoing)
- A production-shaped payment-gateway core covering UPI, cards, netbanking, and wallets, built in the first quarter of the engagement and now under active iteration.
- Audit-ready by design. RBI PA-framework expectations mapped to concrete system behaviour: hash-chained audit log, segregation pattern in the ledger, reconciliation evidence, incident runbooks.
- PCI-DSS scope held to tokenisation-only. UniqPay's own environment never holds raw card data, confirmed by the security engineer who sits inside the pod.
- A dedicated DevOps lane. Infrastructure-as-code, CI/CD, observability, and on-call runbooks owned by one person whose only client is UniqPay.
- An ops team that owns the product without needing engineering. Refund authorisation, dispute walk-through, merchant lookup: all in the console, all role-gated, all logged.
- An engagement that continues to scale. The pod is the same shape four months in (same engineers, same QA, same security, same DevOps), and the relationship is set up to grow the team as UniqPay's roadmap expands.
What we'd repeat
Treating the RBI PA framework as an architecture input rather than a compliance bolt-on changed the shape of the build. The audit log, the ledger segregation, and the reconciliation engine weren't features. They were the foundation. That meant the licence evidence pack at week 16 was a query against the system, not a separate document we had to compile.
The other lesson: ship the ops console next to the API, not after it. The temptation in payment infra is to focus on the public surface and treat internal tooling as a phase-two concern. We did the opposite. By the time the first merchant went live, the ops team already had the console they'd be using daily. That removed the operational risk that usually accompanies a payment-gateway launch.