Real payment requests
For a merchant VPA you enter, each QR and deep link carries the same payee, the exact payment amount, and INR currency. Your UPI app handles the payment. Recipient identity and availability must be checked there.
THE EXPERIMENT / V0.1
Small requests.
Honest boundaries.
SplitUPI explores how one merchant bill can become several clear, trackable UPI payment requests.
Manual tracking today
“Paid” means someone confirmed the payment in this browser. SplitUPI cannot see your bank account or verify a transfer. Local records and printed summaries are not proof of settlement.
A path to verification
A production service would create payment requests through a legitimate PSP or bank integration, verify signed webhooks on a server, and reconcile the payee, amount and transaction reference before marking a request paid.
The ₹2,000 default is just a setting.
It is an editable chunk size for this experiment, not a claim about a regulatory threshold. Choose equal payments, an amount per request, or a custom breakdown. No fee savings or transaction classification is promised.
Your data stays in this browser.
Sessions are saved in localStorage, without an account or a database. Other devices cannot open your session record. Clearing browser data removes it. A shared demo link starts a fresh sample; it never exposes your merchant or invoice.
The demo never initiates a payment.
The sample VPA demo@upi is illustrative and is not a verified merchant. Sample QR codes contain a non-payment demo marker, and UPI app launching is disabled. Enter your own merchant details to generate a real payment QR.
One more important distinction.
The app guides requests one at a time and locks completed payments. A previously copied QR remains usable outside this app. Always check your bank history before retrying a payment; this prototype cannot prevent duplicate bank transfers or reverse payments.
NPCI reference: UPI QR parameters