What is UPI SplitPay?
UPI is India's most-used payment rail with over 14 billion monthly transactions, yet no major UPI app offers a native bill-splitting flow. Users currently split bills by manually calculating amounts and sending separate UPI requests — a broken, multi-step process that causes payment friction in group settings like restaurants, trips, and shared housing.
UPI SplitPay is a proposed native feature that lets a user split a bill among contacts, send individual UPI collection requests, and track who has paid — all within the existing payment app.
UPI transactions/month in India (2025)
Users split bills monthly in group settings
More likely to re-open app with pending split
Why the current flow fails
Today's bill-splitting experience on UPI apps requires users to exit the app, use a calculator or Splitwise, return and manually send individual requests. This creates multiple drop-off points and zero visibility into payment status.
Pain Points Identified
| Pain Point | User Impact | Frequency | Priority |
|---|---|---|---|
| Manual amount calculation | Error-prone, awkward social moment | Every group payment | Critical |
| No payment tracking | Awkward follow-ups with friends | Every group payment | Critical |
| App-switching friction | Users abandon the split entirely | High | High |
| No split history | Disputes over who paid what | Medium | Medium |
| Equal-only splitting | Can't handle unequal shares | Medium | Medium |
PRD: UPI SplitPay
Objective
Build a native bill-splitting feature inside the UPI payment app that allows users to split any amount among contacts, send collection requests in one tap, and track real-time payment status — reducing group payment friction to under 30 seconds.
Scope (In vs Out)
| In Scope (v1.0) | Out of Scope (v2.0+) |
|---|---|
| Equal & custom split among UPI contacts | Non-UPI users (SMS/link payment) |
| Bulk collection request sending | Multi-currency splits |
| Real-time paid/pending status tracker | Recurring splits (subscriptions) |
| Split history (last 30 days) | Integration with restaurant PoS |
| Push notification on payment received | AI-powered receipt scanning |
Functional Requirements
| ID | Requirement | Priority | Owner |
|---|---|---|---|
| FR-01 | User can initiate a split from the home screen or after a payment | P0 | Mobile |
| FR-02 | User selects contacts from phonebook or UPI ID; min 1, max 19 people | P0 | Mobile |
| FR-03 | System auto-calculates equal split; user can override individual amounts | P0 | Mobile |
| FR-04 | Single CTA sends UPI collection requests to all selected contacts simultaneously | P0 | Backend |
| FR-05 | Real-time dashboard shows Paid / Pending / Declined status per person | P0 | Backend + Mobile |
| FR-06 | Push notification triggered when any member pays | P1 | Backend |
| FR-07 | User can send a reminder to pending members (max 1/day) | P1 | Mobile |
| FR-08 | Split history accessible from profile for 30 days | P2 | Backend + Mobile |
Non-Functional Requirements
| Requirement | Target |
|---|---|
| Bulk request API response time | < 1.5 seconds for up to 19 requests |
| Status refresh latency | Real-time via WebSocket; max 3s delay |
| Uptime SLA | 99.9% (same as core UPI payment flow) |
| Data retention | Split history stored for 90 days; purged per RBI data guidelines |
| Accessibility | WCAG 2.1 AA compliant; screen reader support |
Assumptions & Dependencies
• All split members must have an active UPI ID linked to any bank account.
• Existing UPI collection request API is reused; no new NPCI approval required for v1.
• Backend team can support WebSocket connections at existing infrastructure cost.
• UI/UX wireframes to be delivered by end of Sprint 1, Day 3.
Stories & Acceptance Criteria
- "Split this payment" CTA appears on payment success screen
- Split can also be initiated from home screen → "New Split"
- Total amount pre-filled from the last transaction; editable
- Contact picker shows UPI-linked contacts first, sorted by recent
- Default mode is equal split; toggling "Custom" unlocks per-person amount fields
- Live running total shows remaining unassigned amount; must reach ₹0 to proceed
- Max 19 participants enforced with clear error message
- Single "Send Requests" button triggers simultaneous UPI collection requests
- Success confirmation shows how many requests were sent successfully
- Failed requests (invalid UPI ID) shown individually with retry option
- Split dashboard shows each member with Paid ✓ / Pending ⏳ / Declined ✗ status
- Status updates in real-time without manual refresh
- Total collected vs total expected shown with a progress bar
- "Remind" button appears next to each pending member after 2 hours
- Reminder sends an in-app notification + UPI app push notification to recipient
- Rate limited: max 1 reminder per person per day; button disabled after use
2-Week Sprint Plan
Total velocity: 47 story points across 2 sprints. Sprint 1 focuses on core flow (P0 stories); Sprint 2 covers tracking, notifications, and polish.
Backlog (Post v1.0)
| ID | Feature | Priority | Est. Points |
|---|---|---|---|
| BP-01 | Receipt photo scan via camera — auto-populate total | P2 | 13 |
| BP-02 | Non-UPI user support via payment link (SMS/WhatsApp) | P2 | 8 |
| BP-03 | Recurring split (shared rent, subscriptions) | P3 | 13 |
| BP-04 | Group wallet — pre-fund a shared pool | P3 | 21 |
RACI Matrix
Defines responsibility across 5 teams for each major activity in the feature delivery lifecycle.
| Activity | Product (PM) | UI/UX | Backend | Mobile | QA | Marketing |
|---|---|---|---|---|---|---|
| PRD writing & sign-off | A | C | C | C | I | I |
| Wireframes & UI design | C | A | I | C | I | I |
| API development (bulk UPI requests) | I | I | A | C | I | I |
| Mobile app implementation | I | C | C | A | I | I |
| QA & test case execution | C | I | R | R | A | I |
| Go-to-market & launch comms | C | R | I | I | I | A |
| Post-launch metrics review | A | I | C | I | C | C |
How We'll Measure Success
North Star: reduce average group payment completion time from ~4 minutes to under 30 seconds, measured across the first 30 days post-launch.
A/B Test Plan
| Test | Control | Treatment | Duration | Success Criteria |
|---|---|---|---|---|
| Split CTA placement | Home screen only | Post-payment screen + home | 2 weeks | Initiation rate > 8% in treatment |
| Reminder timing | Reminder after 24hrs | Reminder after 2hrs | 3 weeks | Collection rate +10pp in treatment |
| Equal vs custom default | Equal split default | Smart split (based on order history) | 4 weeks | Completion rate > 75%, no revenue impact |