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.
> if the transaction could not go through, it remains pending for 3-ish days while Google retries internally.
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.
Person living in Canada here. I can confirm that Google Pay can take up to 3 days of internal retries here also. I once called and asked about a payment that didn’t go through and if they could just cancel it but apparently after I fixed the issue I was told I just had to wait for the system to retry again on its schedule, not mine. It’s some quirk about Google Pay in that it seems to affect any consumer services whose billing goes through Google Pay. The closest help article I can find on the subject is https://support.google.com/pay/answer/7644013#zippy=%2Csend-... but they really don’t publicize this quirk, that the system retries automatically. It sounds reasonable to do this for a subscription service, say, and when dealing with non-real-time cash transfers between bank accounts, it’s understandable, but paying with a credit card, for example? I expect that to be basically binary for each transaction: it succeeds or it fails. This “pending” with retry just complicated things…
> GPay gained success by offering scratch cards (giving you money) and cashbacks for making payments through GPay.
I remember reading about some anecdote where a network of friends were doing thousands of transactions a day to game the scratch card system. I'm sure they plugged that loophole (if there was ever one) pretty quickly.
Scratch cards "drawing dates" several days after the transaction. Enough time to figure out ring transactions. Google once targeted a friend by making his meal nearly free. He talked about that to several friends for months. His circle got much smaller rewards. Its not truly random.
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.