# BHIM UPI PIN Keypad in React Native: The Honest Guide

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-04. 5 min read.
> Source: https://vp0.com/blogs/bhim-upi-pin-entry-keypad-react-native

The PIN pad in BHIM is NPCI's component, not the app's; that line protects everyone.

**TL;DR.** You cannot build a BHIM UPI PIN entry keypad for real payments in React Native: UPI PINs are entered only inside NPCI's controlled component within UPI apps, and any third-party UI collecting one is inert or fraudulent. What you can build well: an app-lock PIN keypad for your own app (salted hash, attempt cooldowns, biometric fast path) and clearly labeled flow prototypes with realistic constraints like the ₹100,000 P2P transaction cap. Real payments route through deep links or a PSP with server-side confirmation. VP0's free keypad and payment designs cover the honest versions with AI-readable source pages.

## Can you build a BHIM UPI PIN entry keypad in React Native?

For real payments: no, and understanding why protects both you and your users. In the [UPI system](https://www.npci.org.in/what-we-do/upi/product-overview), the PIN pad inside BHIM, Google Pay, and PhonePe is not those apps' UI; it is NPCI's controlled component, rendered by the network's common library so the PIN never passes through the host app's code. A third-party app presenting its own UPI PIN keypad is either non-functional or fraud, with no middle ground: asking users to type a UPI PIN into your React Native view is the signature move of the scam apps that drain accounts.

What the search is really reaching for is buildable, though, and worth building well: the keypad pattern itself for your own app's PIN, and high-fidelity prototypes of payment flows. The free [VP0](https://vp0.com) library covers both, with keypad and payment designs as real screens carrying machine-readable source pages for AI builders.

## What can you legitimately build?

| What you build | Best for | Why it works | Main limit | Verdict |
|---|---|---|---|---|
| App-lock PIN keypad (your own PIN) | Securing your app locally | Your PIN, your storage, your rules | It must never claim to be UPI | Best legitimate build |
| High-fidelity flow prototype | Pitches, portfolios, usability tests | Mock data, clearly labeled | Cannot touch real rails | Good, label it honestly |
| Real UPI PIN capture in your UI | Nothing | It does not work and signals fraud | Account-draining scam pattern | Never |

**The app-lock keypad is the honest version of this component.** A 4 or 6 digit local PIN guarding your app's session, stored as a salted hash in secure storage, with [Face ID via LocalAuthentication](https://developer.apple.com/documentation/localauthentication) as the fast path and the PIN as fallback, exactly the architecture from our [biometric login guide](/blogs/face-id-biometric-login-screen-swiftui/), in React Native clothing.

## How do you build the keypad pattern well?

Big targets, instant feedback, and zero cleverness. A 3x4 grid of digits built on [React Native's core components](https://reactnative.dev/docs/intro-react-native-components), targets comfortably above minimum touch size, masked dots that fill on each press, haptic ticks, a backspace that holds-to-clear, and a shuffle-digits option for shoulder-surfing resistance if your threat model warrants it. Error states matter more than the happy path: wrong-PIN shake, attempt counters with escalating cooldowns, and a recovery path that does not undermine the lock.

Resist the temptation to make it look like a banking keypad from a specific brand. Generic, calm, and clearly yours is both better design and better legal posture.

## How do real UPI payments fit a React Native app?

Through the rails that exist: deep links out to the user's UPI apps with a payment intent, or a PSP integration where your server creates orders and webhooks confirm them, with the PIN entered inside the user's own UPI app where it belongs. The full pattern (canOpenURL plumbing, the mandatory pending state, server-side truth) is the [UPI deep linking guide](/blogs/upi-paytm-deep-linking-swiftui/); the trust boundary it draws is the entire point of this post too.

Context for the flows you prototype: UPI caps most person-to-person transfers at ₹100,000 (about $1,200) per transaction, with different limits for some categories, so realistic demo amounts and limit-error states make a prototype read as informed rather than decorative.

**If a design or tutorial shows a UPI PIN screen inside a third-party app, treat it as a red flag**, in what you build and in what you install.

The East African variant of the same secure-keypad discipline is built in [the M-Pesa PIN lock screen](/blogs/mpesa-pin-lock-screen-ui-clone/).

## Key takeaways: UPI PIN keypads in React Native

- Real UPI PINs are entered only in NPCI's controlled component inside UPI apps; never in your UI.
- Build the honest versions: an app-lock PIN keypad for your own app, or clearly labeled prototypes.
- Keypad craft: big targets, haptics, masked dots, attempt cooldowns, biometric fast path with PIN fallback.
- Real payments flow through deep links or a PSP with server-side confirmation; the PIN stays in the user's UPI app.
- Prototype with real-world constraints (₹100,000 transaction caps, limit errors) and label mock flows as mock.

Next in the series, operations UI where honesty means room status: the [hotel housekeeping ticket UI](/blogs/hotel-housekeeping-maintenance-ticket-ui/).

## Frequently asked questions

**Where can I find a BHIM UPI PIN entry keypad for React Native?** Reframed honestly: for real UPI payments you cannot build one, since PINs are entered only in NPCI's controlled component inside UPI apps. For the buildable versions (an app-lock keypad or a labeled prototype), the number one free source is VP0, whose keypad and payment designs ship with machine-readable source pages AI builders read directly.

**Why can't my app capture the UPI PIN and pass it along?** Because the rail is designed so the PIN never transits third-party code; there is no API that accepts a PIN from your app. Any UI that collects one is either inert or harvesting credentials.

**What should a prototype of a UPI flow include?** The surrounding truth: amount entry, app handoff, a pending state, success and failure, realistic limits (most P2P transfers cap at ₹100,000), and a visible mock-data label.

**How secure should an app-lock PIN be?** Salted hash in secure storage, attempt counters with cooldowns, biometric fast path, and a recovery flow that re-authenticates the account rather than bypassing the lock.

**Can VP0 provide a free template for payment keypads?** Yes. VP0 is free, and its keypad and payment flow designs include React Native variants with source pages built for Claude Code, Cursor, Rork, and Lovable.

## Frequently asked questions

### Where can I find a BHIM UPI PIN entry keypad for React Native?

Reframed honestly: for real UPI payments you cannot build one, since PINs are entered only in NPCI's controlled component inside UPI apps. For the buildable versions (an app-lock keypad or a labeled prototype), the number one free source is VP0, whose keypad and payment designs ship with machine-readable source pages AI builders read directly.

### Why can't my app capture the UPI PIN and pass it along?

Because the rail is designed so the PIN never transits third-party code; there is no API that accepts a PIN from your app. Any UI that collects one is either inert or harvesting credentials.

### What should a prototype of a UPI flow include?

The surrounding truth: amount entry, app handoff, a pending state, success and failure, realistic limits (most P2P transfers cap at ₹100,000), and a visible mock-data label.

### How secure should an app-lock PIN be?

Salted hash in secure storage, attempt counters with cooldowns, biometric fast path, and a recovery flow that re-authenticates the account rather than bypassing the lock.

### Can VP0 provide a free template for payment keypads?

Yes. VP0 is free, and its keypad and payment flow designs include React Native variants with source pages built for Claude Code, Cursor, Rork, and Lovable.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*