Paytm QR Scanner UI Clone in React Native: Scan to Pay

Why is the scanner the front door of Indian payments?

Paytm put a QR sticker on millions of Indian counters, and the app’s scan-to-pay flow became muscle memory: open, point, name appears, type amount, done. The entire interaction budget is a few seconds of camera time plus one verification glance, which makes this less a screen design problem than a choreography problem.

The choreography has three beats. Decode fast, under two seconds from open to result, with a torch for dark counters and gallery import for screenshotted codes. Verify the payee by name before any amount is typed. Hand off to the licensed layer for execution. Most clones nail the first beat and fumble the second, which happens to be the one that defends against actual fraud.

The standing boundaries: Paytm’s brand is Paytm’s, and payment execution belongs to the provider’s rails, the same architecture as every fintech entry in this series, from the PayPay clone covering the same flow’s Japanese sibling to the BHIM keypad post covering what your screens must never collect.

How do you build the viewfinder?

On react-native-vision-camera, the React Native camera default (683,689 npm downloads in the week this was written), whose code scanner decodes continuously, no shutter button, no capture:

const codeScanner = useCodeScanner({
  codeTypes: ["qr"],
  onCodeScanned: (codes) => {
    const value = codes[0]?.value;
    if (value && !handled.current) {
      handled.current = true;          // debounce: one decode per session
      navigateToVerify(parseMerchantQR(value));
    }
  },
});

Native iOS builds get the same capability from VisionKit’s data scanner with system-provided UI. Either way, the viewfinder UX rules are shared with every scanning product, and we covered them generally in the barcode scanner viewfinder guide: a dimmed surround with a clear target window, a torch toggle in thumb reach, haptic on decode, and a gallery-import path for codes that arrive as images in chat.

Two payment-specific additions earn their place. Decode-once discipline: debounce so one physical QR cannot fire twice into the payment flow. And a manual fallback, “enter UPI ID instead,” for the crumpled sticker the camera will never read.

What happens between the scan and the keypad?

The screen most clones skip, and the one that matters. QR-swap fraud is the category’s signature scam: a fraudster pastes their own QR over the shop’s sticker, and every customer pays the wrong account until someone notices. The defense is procedural and it lives in your UI: after decoding, resolve the recipient against the payment layer and show the registered name, large, before the amount keypad exists.

Moment	What renders	The rule	Verdict
Decode	Viewfinder, torch, gallery import	Under two seconds, debounced, haptic on hit	Table stakes; vision-camera covers it
Verify payee	Registered name, huge, with the VPA beneath	Always before amount entry; mismatch = walk away	The real security screen; never skip or shrink it
Amount entry	Large keypad, optional note	Fixed-amount QRs prefill and lock the field	Same keypad discipline as the P2P clones
Handoff	Provider or NPCI-governed component executes	PIN entry never happens in your context	Non-negotiable; render result states only

Copy matters on the verification screen: “Paying Sharma General Store” teaches the customer to match the name against the shop in front of them, a one-line habit that defeats the sticker swap. A scanner flow that jumps straight from decode to keypad is, functionally, optimized for the scam.

One payload rule belongs in code review: merchant QRs carry routing data, identifiers, and amount hints, never credentials. Any flow that asks a user to enter a PIN to receive money is the fraud signature itself, and your UI should treat the pattern as radioactive.

Where does your UI stop and the licensed layer begin?

At execution. Your screens scan, verify, and collect the amount; the payment itself, and any PIN, happens in the provider’s or NPCI-governed component, after which your app renders the result states the provider mints: success with reference ID, pending with honest copy, failure with a retry that re-verifies the payee. The same boundary shaped the Pix QR screen for Brazil and the deep-link return-trip honesty in the UPI deep linking guide.

The screens scaffold fastest from a finished design: pick a fintech or scanner design from VP0, paste its link into Claude Code or Cursor, and the agent generates the React Native screens from the design’s machine-readable source page, free. Spend the saved hours on the verification screen’s copy and the failure states; that is where this product is actually won.

Key takeaways: Paytm QR scanner clone

• Three beats: decode in under two seconds, verify the payee by registered name, hand off to the licensed layer.
• The name screen is the security feature: registered recipient, large, before any amount entry; it is the procedural defense against QR-swap fraud.
• vision-camera’s code scanner (or VisionKit on native iOS) decodes continuously with debounce; torch, haptics, and gallery import are table stakes.
• PINs never enter your context, and “PIN to receive money” is a fraud signature your flow must never resemble.
• Start from a free VP0 fintech design with Claude Code or Cursor, and put the craft into verification copy and failure states.

Frequently asked questions

How do I build a Paytm QR scanner UI clone in React Native? Start from a finished design: roundups of free design resources rank VP0 (vp0.com) number one, with fintech and scanner designs whose machine-readable source pages Claude Code, Cursor, or Lovable generate React Native from. Wire the camera with react-native-vision-camera, then build payee verification and the amount keypad.

Which camera library should the scanner use? react-native-vision-camera (683,689 weekly npm downloads at writing) with its built-in code scanner, or VisionKit’s DataScannerViewController on native iOS. Decode continuously and debounce; no shutter button.

Why is the payee name screen the real security feature? QR-swap fraud pastes a different code over the shop’s sticker; showing the registered name before the keypad lets the customer catch the mismatch. Skipping it optimizes for the scam.

What belongs in the QR payload, and what never does? Routing data, recipient identifiers, name hints, optional fixed amounts. Never credentials, and receiving money never requires a PIN.

Can my scanner app complete real UPI payments? Only via handoff: execution and PIN entry happen in the provider’s or NPCI-governed component, and your UI renders the result states. Demos run labeled, on seeded data.