When RBI mandated wallet interoperability, BlackBuck needed to build a full UPI product — from scratch, on a PPI wallet, for a user base that already had strong opinions about what payments should feel like.
Screens across 8 flow areas — onboarding, 4 payment methods, transaction history, autopay, UPI management
Phone number, UPI ID, bank A/C, and QR — one unified experience across all payment methods
PPI wallet interoperability compliance achieved — closed-loop wallet now open via UPI
BlackBuck Pay is a full UPI product built on a closed-loop PPI wallet inside the Zinka app. Users can send money, pay merchants, set up recurring payment mandates, scan QR codes, and manage their payment history — on the same rails as GPay or PhonePe, but sourced from the BlackBuck wallet. M2P's headless SDK handles the backend. BlackBuck owns every screen.
The product exists because it had to. RBI mandated that PPI wallets become interoperable via UPI — meaning the existing closed-loop wallet had to open up. The design challenge wasn't building a compliance checkbox. It was building something users would actually choose over the apps they were already using.
BlackBuck's platform serves commercial fleet operators — individual owners managing a handful of trucks through to businesses running hundreds of vehicles. They use GPay and PhonePe daily. That's the bar the product had to clear.
On paper, the brief was: add UPI to the existing wallet. In practice, every decision was pulled between what the system needed to be and what the user expected to experience.
The product had to feel like something users already knew — while running on infrastructure they'd never encountered.
The first tension was technical transparency vs. user simplicity. UPI on a PPI wallet isn't the same as bank UPI — different rails, different limits, different compliance requirements. None of that could be visible.
The second was system truth vs. user mental model. The PPI wallet and FASTag wallet are technically separate — separate limits, separate flows, separate regulatory treatment. But to the user, it's all just money in the app.
The third was trust at scale. Autopay mandates, UPI PIN flows, disputes — these are features where getting the error state wrong doesn't just confuse users, it breaks trust permanently.
The initial proposal was to show three numbers — FASTag balance, UPI balance, and a combined total. The logic was transparency. The problem was a question the UI couldn't answer: which of these balances will actually be used when I make a payment?
Showing information the user can't act on isn't transparency — it's noise. The call was to show only the UPI balance on the payments screen. The edge case — a ₹2 lakh combined wallet limit — was handled contextually, appearing as an inline error at the exact moment a user hits it during recharge.
V1 showed 3 separate balances. V2 shows one — answering the only question that matters at the moment of payment: how much can I pay right now?
Before designing a single screen, I mapped how GPay, PhonePe, and Paytm handle each transaction type — what they surface on the card, what they push into the detail view, what they label and how. Not to copy, but to understand what users were already trained to expect.
The design question: what's the minimum information on a transaction card for the user to understand what happened — without opening it? The answer: status → direction → amount → counterparty. In that order. Everything else lives a tap away.
Transfer history — each card surfaces the minimum needed to understand what happened without opening it.
Every transaction state designed end-to-end: success, processing, failed, refund initiated, debit reversal, timeout, and debit failed.
BlackBuck Pay supports UPI AutoPay — users can authorise recurring mandates, setting it as the payment instrument for any merchant that accepts UPI autopay. Paying someone on demand is one thing. Handing a merchant recurring access to your wallet is another.
There are eight distinct ways an autopay flow can go wrong — mandate declined, debit above ₹15k limit, insufficient balance, timeout, expiry, API failure on pause or cancel. Each one is a different situation requiring a different response. Treating all of them with a generic "payment failed" would have been easier. It would also have been wrong.
Pause, resume, and cancel had to be equally visible entry points — not buried in settings. A user who can't easily see how to stop an autopay won't set one up.
Happy flow · Debit above ₹15k success · Debit within 1 min · QR scan mandate registration
Mandate declined · Timeout · Registration failed · Expiry · API failure on pause / resume / cancel
Full autopay mandate setup flow — merchant checkout to autopay confirmed. Pause and cancel are always one tap away.
The three decisions above carry the most design weight. Every flow below went through the same process — understand the system, map the failure states, design for the edge cases first.
Pay Anyone — multi-search supporting phone number, name, and UPI ID. Full end-to-end flow from contact selection to payment success and balance update.
Pay Bank Account — IFSC verification happens inline as the user types. No separate lookup step, no dead end.
Pay via QR — scanner to payment success in one uninterrupted flow. Transaction detail dropdown visible immediately on success.
Manage UPI IDs — activate all, copy, and disable with confirmation bottom sheet.
Manage UPI Number — add or remove the mobile number linked to your UPI ID.
Phase 1 was intentionally gated — the business team wanted whitelisting to be difficult to discover, so the feature wouldn't cannibalise other paid offerings. That was a valid call and I designed within it. But the onboarding experience was built for a high-intent user who'd already gone through the effort of getting access.
When the product opened up, that assumption didn't hold — the onboarding tone carried too much implicit context that a cold user simply wouldn't have. In hindsight, I'd push earlier to design both versions in parallel — a gated flow for Phase 1 and a cold-user flow ready for when the gates opened. The effort delta is small. The cost of retrofitting tone at scale isn't.