| Person living in India here. GPay gained success by offering scratch cards (giving you money) and cashbacks for making payments through GPay. From a UX perspective, it has been notoriously slow and is prone to failures. For example, if the transaction could not go through, it remains pending for 3-ish days while Google retries internally. For real-time transactions, like buying groceries from a street vendor, it isn't practical to wait so long to find out - and mostly results in people paying twice for a product. Aside from marketing gimmicks and usage by vendors, who by the way use a single QR across 5 different UPI vendors, I'm not sure it really is a "runaway success". Edit: Another point to note is that GPay (and other vendors like PhonePe) went around sticking their own QR codes on every shop. This meant that if you wanted to pay by UPI at that shop, you had to install GPay. This prompted NPCI to issue a circular and ensure QR codes were interoperable across UPI apps - but as I've seen, there still remain tons of shops which have only the GPay proprietary QR Code. Ref: https://razorpay.com/blog/npci-circular-on-upi-interoperabil... Lethargy by vendors to move over to the new QR could also be one of the reasons why these 2 players hold the lions share in the UPI market. |
To be clear, the transaction isn't retried. The backend keeps trying to fetch the transaction status until it gets a definitive success/failure from the PSP/issuer.
I agree with your comment though; payments is a frustrating UX if the backend isn't nearly 100% reliable.
UPI in particularly has a dozen or so moving parts in the OLTP path each of which are 90-95% available at best.
From the insiders, I know that issuing banks aren't incentivised to invest in their UPI stack to make them highly available or reliable. That's because government has banned interchange fee on UPI transactions and it wants issuers to absorb the cost of maintaining their UPI stack. So the issuers let that tech stack languish doing their absolute minimum to keep it running.
This is a great example of forcing a party to participate in a transaction and at the same time not pay them to maintain the system. It ends up being counterproductive in terms of frustrating UX and more.