Dynamic QR

The Problem

For a long time, field collections ran almost entirely on cash. An agent would visit a delinquent customer, collect the overdue amount in hand, and submit it later. The process worked, but it came with all the risk and friction that cash handling brings on both sides.

The shift toward digital had been gradual. The first attempt was simple: agents would send a payment link over SMS or WhatsApp. The problem was obvious: even with an official Bajaj Finance SMS header, a link asking you to click and pay money mirrors one of the most common scam formats in India. Customers ignored it, and agents couldn't do much to convince them otherwise.

The next step was Collect Request. The agent would open the field agent app, pull up the customer's UPI ID, and trigger a collect request directly. That request would land as a push notification inside the customer's most-used UPI app, PhonePe or GPay, prompting them to approve the payment.

On paper, this was better than a link. In practice, the trust problem didn't go away. It just moved. The agent would tell the customer a payment request was on its way before sending it, so the notification itself wasn't a surprise. But the customer still had to authorize a specific transaction inside their UPI app, and that moment of authorization is exactly where scam patterns live. Knowing a request was coming didn't make it easier to trust the one that showed up. For a large portion of customers, that specific transaction still read as risky enough to hesitate on. The agent standing in front of them couldn't override that instinct.

Digital payment adoption stayed stuck. We were collecting ₹1 Cr monthly through digital channels despite an active field presence that reached millions of customers.

What I Found

Collect Request had a trust problem, and it wasn't one you could fix by redesigning the notification or adding more information to the screen. The issue was structural: the customer was being asked to act on an incoming request with no visual confirmation they could validate themselves. Customers trusted Bajaj Finance as a brand. The fear was impersonation, not the brand itself. The mental model it created was "this says it's from Bajaj, but what if it isn't?"

The fix was in rethinking who initiates and who validates. In every payment interaction customers already trusted (scanning at a kirana store, paying a local vendor), the customer held the QR code. They scanned it. They chose to pay. The payee never pushed a request at them. That's what kept control with the payer.

If the agent could generate a QR code and the customer could scan it on whatever UPI app they already used, the dynamic shifts. The agent stops initiating a pull from the customer's account. The customer makes a payment they've decided to make, to a payee they can read on their own screen.

One more thing worth noting: NPCI later confirmed it would discontinue P2M Collect Request in early 2026. That made the QR shift a strategic necessity, not just a UX call. We didn't build Dynamic QR because of that ruling, but it was the right direction regardless.

What I Did

Built the underlying payment infrastructure, since no agent-initiated version of this existed. Some dynamic QR capability already existed at the brand level, for walk-in customers scanning at a branch, but nothing supported an agent generating a QR on the spot for a specific loan account. We created a new merchant ID specifically for the field agent app and integrated PayU as the payment gateway. We built a reverse stamping API on the app side and handed it off to PayU to integrate, so that whenever a payment resolved (success, failure, or pending), the status flowed back automatically. The app then pushed that status into the loan management system, so the payment reconciled against the right customer and loan account without manual intervention. This wasn't a configuration exercise; it was a build, done jointly with the tech and payments teams.

Designed the agent-side flow within the field agent app. The agent opens a case, enters the outstanding EMI amount, and generates a scannable QR code on their device. The QR page displayed everything the customer needed to verify before paying: the Bajaj Finance logo, UPI app logos, the customer's name, customer ID, loan account number, amount to be paid, and a unique transaction ID. No ambiguity about who the payment goes to, for how much, or for which loan.

Designed the customer-side experience to require nothing new. The customer scans with PhonePe, GPay, Paytm, or their bank app. They see "BAJAJ FINANCE LTD." as the payee and the pre-filled amount. They authorize. No app to download, no unfamiliar interface, no incoming request to accept or reject.

Ran Dynamic QR alongside Collect Request rather than replacing it. Agents could offer whichever mode worked for the customer in the moment. This also gave us a read on comparative adoption before Collect Request was wound down.

What Changed

Monthly digital payment volume went from ₹1 Cr to ₹82 Cr over 18 months, with no change to the customer base, the agent team, or the collection process. Only the payment format changed. The customer went from approving a request pushed to their phone to scanning a code on their own terms.

What I'd Do Differently

We had data showing Dynamic QR was outperforming Collect Request on adoption fairly early. We still ran both modes in parallel longer than we needed to. If I were sequencing this again, I'd have moved faster to sunset Collect Request for agent-assisted cases once the signal was clear. We waited for more certainty than the data actually required.