Introducing Bill Payments with
Reward Points
TEAM
Designer
Product Manager
3 Engineers
ROLE
User Research
Conceptualisation
Design
Dev Hand-Off
DURATION
2 Months
OVERVIEW
Turning unavoidable payments into a repeatable value loop
Bill payments are among the most frequent financial actions users perform every month, yet they traditionally create no value beyond task completion. Inside TWID, rewards were already driving value during discretionary spends, but the most consistent payment behavior bills remained outside the ecosystem.
BBPS brings these everyday payments into TWID, enabling users to burn rewards to reduce mandatory expenses or earn rewards on unavoidable spends. This shifts bill payments from a transactional necessity to a reliable habit loop, strengthening repeat usage while preserving the trust and simplicity users expect from utility payments.
PROBLEM SPACE
Scaling bill payments across 40+ categories required a modular system, not isolated flows
BBPS was a critical integration for TWID, unlocking a high-frequency revenue stream while improving user convenience by bringing bill payments into the app. But BBPS is not a single use case. It spans 40+ biller categories, each with different fetch rules, input structures, payment exactness, settlement behavior, and compliance requirements.
Designing category-specific or one-off flows would have slowed rollout, increased maintenance overhead, and made future expansion expensive for product and engineering. The system needed to ship quickly for initial categories, while remaining flexible enough to support dozens more without rework.
The core problem was how to design a modular, scalable bill payment system that could absorb category-level complexity, meet regulatory constraints, and enable fast expansion — without fragmenting the user experience or the underlying product architecture.
RESEARCH
Market learnings and gaps
We studied how large platforms like PhonePe, CRED, Navi, and Google Pay structure bill payments at scale. A few patterns were consistent: billing categories were prominently placed, high-volume categories were prioritized on the homepage, credit card flows showed light personalization, new bills required minimal steps, and the overall structure remained consistent across categories.
However, gaps were equally clear. Rewards and discounts lacked transparency, paid bills often stayed visible even when settled elsewhere, creating user anxiety, and recurring payments had limited automation, with weak or fragmented support for autopay.
These insights shaped our direction: adopt the clarity and consistency of market leaders, while fixing the gaps around rewards, status, and recurrence.
Understanding system and technical feasibility
BBPS in TWID is external API powered, making system behavior unpredictable by default. The design had to interpret variable data, handle failures, and stay compliant, while remaining consistent across 40+ categories.
We designed for dynamic biller data, including a logo system with fallbacks, API latency with controlled loading states, and variable input fields driven entirely by biller responses. Since biller downtime isn’t reliably exposed, the experience required clear downtime and retry handling.
Payments introduced further constraints: reward redemption sequencing, category-based payment restrictions, and eligibility differences between new and recurring users, especially where TWID UPI onboarding was mandatory. All flows had to meet NPCI and BBPS compliance around deterministic payment states, accurate status handling, and transparent fees.
Feasibility here meant building a system that stays predictable, compliant, and scalable, even when the underlying infrastructure isn’t.
OBJECTIVE
Ship BBPS fast, at scale, with clear reward visibility
Design a modular, NPCI-compliant BBPS system that could be rolled out quickly and scale across 40+ biller categories without rework.
The system needed to handle external API variability, category-level payment and reward restrictions, and new versus recurring user flows, while maintaining a consistent, low-friction experience with continuous reward visibility. At the same time, it had to meet regulatory requirements and unlock a sustainable, recurring revenue stream for TWID.
IMPACT
Impact on Users
BBPS turns bill payments from a necessary chore into a value-generating routine.
Users can now:
Save money by burning rewards on unavoidable bills
Earn rewards on expenses they were already making every month
Pay bills with clear amounts, due dates, and status visibility, reducing anxiety around failures and pending payments
By embedding rewards into familiar BBPS flows, users don’t need to learn a new behavior. They simply get more value from an existing one, without added effort or decision fatigue.
Impact on Business
BBPS anchors TWID into users’ monthly financial behavior.
From a business lens, this unlocks:
Higher transaction frequency, with TPC expected to grow from ~3.5 to ~5.5 per user
Increased GMV per installed user, with an incremental lift of ~₹1000 driven by bill payments
Predictable, repeatable usage, shifting TWID from occasional rewards usage to a monthly default
New revenue streams through convenience fees on burn transactions, while maintaining issuer alignment
Most importantly, BBPS strengthens TWID’s position as a payment intelligence layer, present at the most frequent and high-trust moments in a user’s financial life.
FINAL SOLUTION
1. User Flow as the Primary Abstraction
Bill payments were designed as a predictable, linear flow, regardless of biller complexity or payment method.
For first-time and non-recurring payments, the flow follows a clear six-step structure: Category Listing → Biller Selection → Customer Details → Bill Fetch → Payment Method Selection → Payment Confirmation
For recurring users, the flow collapses intentionally: Fetched Bill → Payment Method Selection → Payment Success → Payment Confirmation
This reduction respects user intent. Once trust is established, the system gets out of the way and optimizes for speed.
2. Scalable System for Categories and Billers
BBPS categories and billers vary widely in structure, metadata, and input requirements. Instead of designing per-category experiences, the system was built around reusable primitives.
Key components include:
A single category listing framework adaptable to current and future BBPS categories
A unified biller listing with support for logos where available and identifiers where not
Flexible customer input modules supporting 2–3 variable fields driven entirely by biller configuration
This ensured new billers could be added without redesigning the experience each time.
3. Third-Party Payment Status as a First-Class State
Bill payment confirmation depends on third-party systems, making delayed or pending states unavoidable. Instead of masking this complexity, payment status was treated as an explicit part of the experience.
Clear states were designed for:
Payment initiated
Payment in progress
Payment successful or failed
This reduced uncertainty and reinforced trust, especially in cases where confirmation was not instantaneous.
4. Prioritizing What Users Pay Most
To reduce discovery effort, the system surfaces top bill categories directly on the homepage and reinforces them in the listing view using visual tags.
For returning users, saved and recurring bills are given higher prominence with quick-pay actions. This allows users to complete payments with minimal navigation, turning repetition into efficiency.
5. Handling Credit Card Payments Outside the Native App
Credit card bill payments are handled through an external web-based flow due to platform constraints. Instead of treating this as a limitation, the experience was designed to feel intentional and continuous.
This approach also created an opportunity to re-engage dormant credit cards, while keeping the core TWID app focused on rewards and UPI-led flows.
6. Designing for Future Automation Without Lock-In
Features like autopay and recurring bill automation were explored but intentionally paused. The system was designed to support these capabilities later, without committing users prematurely to automated reward logic.
This ensured the current experience stayed simple, while remaining structurally ready for future expansion.
