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.

The link above, which has data from NPCI, says it processed Rs 1,61,418.19 crore in Nov, 2nd only to PhonePe at Rs 1,75,453.85 crore.

They did misuse their place as the company that owns the software platform that runs on 75% of the mobile devices to do this though. When they launched google pay, it was called "tez" (not sure what it means - probably hindi for speed), only to be changed it to google pay so that when people search "pay" for the paytm app that was the market leader in this space, "google pay" comes first. They did have much better UX than paytm and bhim upi (government provided app for UPI interface) apps, but they still had to rely on unethical app renaming to corner the market.

IIRC it was already a hit as Google Tez, probably because it is a much better name. The google pay re-branding was done when it had already proven to be a huge success, probably with a long-term goal of merging it with the international Google Pay.

I don't think it is really throwing shade at Google Play in India (other than that luke-warm line). I think the main argument is that they didn't really adapt the app to the US market. It would have been trivial to be able to look up an account by email OR phone number OR username but they didn't even bother. They also could have transitioned user accounts but didn't care enough.

The article mostly seems to be complaining that good in India != good in US and that Google needs to adapt to the different markets.

> in India, thanks to UPI you can pay anybody if you know their phone number

Or their UPI ID. it looks something like "myname@bankname"

> in India, thanks to UPI you can pay anybody if you know their phone number

Not true. You need the UPI ID of the person, which may probably be phone@bank or phone@paymentsbank. If you assume that everyone is using only Google Pay (or Paytm or PhonePe or Amazon Pay or pick another provider), then those providers would know the UPI ID to connect people to for payments. For people who don’t use these payment services but do have a bank account (say, HDFC or SBI or ICICI), there’s no way you could pay them only by knowing their phone numbers without knowing the bank they have the account with and the bank suffix they use for the UPI ID.

In Australia you can do it too using what is called PayID. But it doesn't require any special 3rd party app. Almost every bank's own app or online banking allows you to do it and payment is instant.

Only thanks to the government making it a requirement. We would still be stuck in the stone age if it was up to the banks to organize this themselves.

In Poland such system (Blik) was created by cooperation of multiple banks. You can pay online, in stores, withdraw cash from ATM or just send money P2P using other person phone number. It works like 2FA (you have to enter code generated in app on pinpad and confirm on phone) so it's a bit more of a hussle than qr codes, but... it just works.

My bank integrates with this service, which seems to let you send money to anyone via their phone or email: https://www.zellepay.com/

I exclusively pay with Gpay these days here in India.

There is no requirement to link Aadhaar with bank accounts or provide it to banks. That coercion was banned by the Supreme Court in its 2018 verdict. UPI is a mobile solution that requires a mobile phone number that’s linked to one’s bank account. It doesn’t need anything else (other than the account holder’s consent for UPI).

I know. Only the account discovery works way better if your adhar and mobile number are linked to all your accounts. I've seen it fail otherwise.

Banks cannot store Aadhaar numbers and allow it to be used for or enable better discovery. Phone number linked to the account is what’s important. Aadhaar is required only if/when receiving government subsidies in one’s bank account. It has nothing to do with person to person transfers.