UPI and Real-Time Payments

Third-party QR libraries are built for general use cases. In a payments context, detection speed and reliability across device types and lighting conditions directly affect transaction completion rates. Our scanner is built on native camera APIs — Objective-C on iOS, Java on Android — which gives us control over frame processing, focus behaviour, and fallback logic that a library wrapper does not expose. The result is sub-1-second detection in real-world conditions, including on lower-end devices that represent a significant share of the active user base.

NPCI periodically releases updated SDK versions, and managing these across a large active user base requires tracking which SDK version each device is running and handling version-specific behaviour differences. We manage this through React Native Keychain, where SDK version metadata is stored alongside authentication tokens. This keeps version management at the secure storage layer rather than in application state, and allows version-specific handling without requiring users to update the application before completing a transaction.

Every UPI transaction passes through three systems — the bank, Mindgate as the payment service provider, and NPCI. A failure or discrepancy at any layer can produce a transaction state that is ambiguous from the user's perspective but needs to be resolved definitively for settlement purposes. Our audit trail captures state at each of the three layers independently, so operations teams can identify exactly where a transaction diverged from expected behaviour without reconstructing the sequence from fragmented logs.

Race conditions occur when concurrent API calls — for example, a user tapping pay while a preceding request is still in flight — produce conflicting transaction states. Without explicit handling, this can result in duplicate debits, stuck transactions, or states that require manual intervention to resolve. We implement locking and request deduplication at the API call layer, so concurrent requests resolve to a single deterministic outcome regardless of network timing.

Most UPI applications only manage UPI IDs linked to accounts held at the primary bank. Third-party bank UPI management allows users to link and transact from UPI IDs associated with accounts at other banks — within the same application. This requires handling multiple VPA registrations, separate token sets per linked bank, and bank-specific flow variations within a unified interface. It is uncommon because the integration complexity is significant, but it is what allows users to manage their complete UPI footprint from a single application.

A full UPI system — covering registration, custom QR scanner, P2P and P2M transfers, collect requests, mandates, and biometric authentication — built on React Native with NPCI SDK integration typically runs fourteen to twenty weeks from architecture sign-off to production. The range depends on the number of transfer types in scope, the complexity of the bank's existing authentication infrastructure, and whether third-party bank UPI management is included. We assess scope during the discovery phase before committing to a timeline.

Yes. The shared application layer is built in React Native with TypeScript. The QR scanner, biometric authentication, and Keychain token management use native Objective-C on iOS and Java on Android — because these functions require platform-level access that a cross-platform layer cannot reliably provide at the performance and security standard a payments application requires.

The system is handed over production-ready, load-tested, and documented. Your team can maintain and extend it independently. We do not build on proprietary frameworks that require ongoing vendor involvement to operate. If your team wants a formal support arrangement post-launch, that is a separate conversation.