Architecting on UPI, ONDC and Aadhaar-Class DPI Rails

Q: What is digital public infrastructure and how is it different from a payment gateway or marketplace platform?

Digital public infrastructure (DPI) refers to population-scale, openly specified digital rails — payments, identity, data exchange, commerce — operated as public or quasi-public utilities rather than as commercial platforms. India's stack is the canonical example: UPI for real-time payments, Aadhaar for identity, the Account Aggregator framework for consented financial data sharing, and ONDC for open-network commerce. The difference from a gateway or marketplace is contractual as much as technical: a vendor sells you a bundled service with an SLA, liability terms, dispute machinery and a support organisation, while a DPI rail publishes a protocol and moves messages. You gain reach no vendor can sell — UPI alone processed 24.51 billion transactions in August 2026 — but every operational guarantee you would normally buy has to be engineered on your side of the integration boundary or absorbed by a licensed intermediary you choose.

Q: Do I integrate with UPI directly or through an intermediary?

Almost nobody talks to the NPCI switch directly. The integration ladder runs from thickest to thinnest intermediary: a payment aggregator gives you the fastest launch with the most operational cover and the highest per-transaction margin cost; a direct TPAP (third-party application provider) relationship riding a PSP bank's connection gives more control and obligation; and bank-grade participants operate deepest in the stack. The right pattern is to launch through the thickest intermediary your unit economics tolerate, build your own ledger, reconciliation and fraud decisioning from day one regardless, and only move down the ladder when transaction volume justifies swapping intermediary margin for licensing and compliance obligation. Whichever rung you choose, the intermediary's uptime, rate limits and compliance posture become yours, so evaluate them like a critical vendor even though the rail behind them is public.

Q: Why does a UPI integration need its own ledger and reconciliation if the PSP has a dashboard?

Because the rail's record is authoritative for the rail, not for your business, and because UPI is asynchronous underneath its synchronous appearance. A debit can succeed while the confirmation times out; callbacks can arrive twice or not at all; transactions can sit in deemed states that resolve hours later. Without a client-side idempotency key, an explicit state machine for pending and deemed states, and an internal append-only double-entry ledger reconciled daily against PSP and bank reports, you cannot distinguish a failed payment from a stuck one, cannot prove your position in a dispute, and cannot answer basic questions about your own money flow during an audit. On a rail without chargeback economics, your ledger and your reconciliation diffs are your only evidence — the PSP dashboard is a view of someone else's system, not a system of record.

Q: How does fraud handling on UPI differ from card payments?

Card networks give merchants and issuers a chargeback mechanism with defined liability shifts, evidence windows and dispute arbitration measured in days to weeks. UPI settles account-to-account in seconds, and dispute resolution runs through bank-side processes you neither control nor should build your economics on. The RBI's customer-protection framing limits customer liability for unauthorised transactions, but there is no equivalent of a merchant chargeback flow to recover fraud losses after the fact. The architectural consequence is that fraud decisioning must move pre-transaction: velocity limits, device binding, payee and collect-request risk scoring, and mule-account pattern detection have to run before the money moves, because the recovery window afterwards is minutes, not days. Most UPI fraud attacks the human rather than the protocol — collect-request social engineering, fake support numbers, screen-sharing scams — so the scoring has to model behavioural context, not just transaction parameters.

Q: What is the Account Aggregator framework and what does an FIU actually have to build?

The Account Aggregator (AA) framework is India's RBI-licensed consent-broker network for financial data: FIPs (financial information providers — banks, insurers, mutual funds) hold data, FIUs (financial information users — lenders, PFM apps, advisors) consume it, and licensed AAs sit between them moving encrypted data against a customer-approved consent artefact that specifies purpose, data range, frequency and expiry. An FIU has to build considerably more than an API client: a consent state machine covering the artefact's full lifecycle (requested, active, paused, revoked, expired), fetch scheduling that respects the artefact's window and survives slow or flaky FIPs, data lineage linking every derived feature and model input back to the consent that authorised it, and purge workflows that actually delete derived data on revocation or expiry. Under the DPDP Act this consent plumbing is not good practice but the compliance surface itself.

Q: Is building on ONDC worth it in 2026?

Treat it as a strategic learning investment with real but early volume, not a near-term revenue line. ONDC unbundles the marketplace into network roles — buyer apps, seller apps, logistics providers — speaking the Beckn protocol through a gateway, which gives a buyer-side builder access to the network's seller base without building supply. The costs are symmetrical: there is no platform operator between roles, so catalogue quality, cross-participant order reconciliation, fulfilment failures and customer support all land on you, with the network's issue-and-grievance protocol as machinery rather than an Amazon-style support organisation behind it. The network's economics — who funds discounts, how logistics pricing settles — were still being negotiated in 2026, so the sound architecture isolates ONDC-specific assumptions behind an adapter so that repricing or protocol evolution does not mean rebuilding your core.

Q: How should a product handle Aadhaar authentication failures?

As a designed customer segment, not an edge case. Biometric authentication failure rates are highest for exactly the populations financial-inclusion products target — manual labourers whose fingerprints are worn, the elderly, and users in low-connectivity settings. UIDAI provides multiple modalities: fingerprint, iris, face authentication, OTP to the registered mobile, and offline verification via signed XML or QR code that avoids the online authentication path entirely. A production KYC flow needs an explicit fallback ladder across these modalities, ending in a fully assisted path, with metrics on how often each rung is used so exclusion is visible in a dashboard rather than in customer complaints. Offline Aadhaar verification also avoids the AUA/KUA licensing gate for many use cases, which makes it the right first rung for products that need identity assurance but not online biometric authentication.

Q: What parts of a DPI integration are the durable competitive moat?

Not access — the rail's entire point is that access is commoditised, and your competitor integrates the same protocol next quarter. The durable moat is the operational layer: reconciliation that closes at T+0 with a per-mille break rate your finance team trusts, pre-transaction fraud decisioning tuned to rail-specific attack patterns, degraded-mode automation that keeps checkout alive through bank-side outages, consent lifecycle management that passes DPDP audits without a scramble, and support tooling that traces an order or transaction across network participants your agents cannot see inside. These compound with volume and are invisible in a demo, which is exactly why they are defensible. The rail gives everyone the same protocol; it does not give everyone the same operation.