Google Pay team reportedly in major upheaval after botched app revamp | Hacker News Reader

Google Pay team reportedly in major upheaval after botched app revamp

arstechnica.com

31 pointsblacktulip14 comments

I felt like it was a massive, invasive, annoying step back. I mean google has for how long focused on building their single sign on for all their services, then suddenly fuck you, no website, and give me your telephone number because why not.

Even though I have been using google wallet for like a decade suddenly its going to take like 10 days to verify and send payment.

I can't believe that this got off the ground, that someone with enough stroke at google didn't see this, and say no.

Well just one more thing that google has manage to wreck for themselves.

This isn't the first time Google ditched its single sign on system. Remember Allo? If I had to guess, this disaster had the same root cause. Somebody looked at how WhatsApp (or in this case, Paytm) took off in India by using the phone number as ID and decided the way to get more users was to copy that aspect of it, skipping any migration plan to get to market quicker. This alienates all the existing users of Hangouts or old Google Pay in currently high value markets, and nobody at the company cares enough to stop it.

> Sengupta departed Google one month after killing the old Google Pay and making his new app mandatory for all users in the US

Doesn't this reflect badly on one's resume? If you are an exec leading a major initiative, wouldn't you be expected to stay on board and steer the ship through troubled waters? What's the point of a captain who is present only in merry weather, but jumps ship at the first sign of trouble?

"Help starting a major rewrite in an innovative and market disruptive framework".

How? "Was at Google, lead and pushed release of a mayor product worldwide" is $$$.

The issue that Google Pay has is that they don't block the bank apps from doing their own payments via the NFC hardware like Apple does. And, as such, the banks here in Australia all opt to do their own tap and pay (https://www.commbank.com.au/digital-banking/tap-and-pay.html) as they want to 'own' the experience.

They fought the good fight against Apple for awhile - not least of which that they didn't want to pay Apple a percentage of each transaction. But, they eventually all caved to Apple Pay as it was the only way to get it on iPhones which have a majority (56%) marketshare here and people were citing it as a reason why they were changing to the (usually smaller) banks that did offer it.

I am kind of glad they did as I really like the Apple Pay experience and trust the to get it right more than the bank's very hit-and-miss mobile app teams...

https://www.macrumors.com/2020/04/28/westpac-australian-bank...

https://www.statista.com/statistics/861532/australia-mobile-...

Australian bank cards like Westpac work fine in Google Pay, its not like they're locked into bank apps.

The bigger problem with Google pay is that it's too slow to open now after the rewrite. It's a time critical app, you're holding up people waiting in line.

The moment I downloaded the new version, without even having used Gpay for years — I knew — I knew they used some web-based or write-once bullshit just by the latency in the tab swipes alone, I can discern it distinctly and am sensitive to these deficits in performance (unfortunately).

Then I thought, "ah shit" searched "Flutter Gpay" and sure enough.

Sigh. When will they learn.

Ads rescued Dart from dying, because when Chrome abandoned the project, then just had gone through the GWT to Dart rewrite.

Flutter then gave Dart extra resources by picking it instead of JavaScript.

Since then they have been on a crusade to keep Flutter relevant.

For me it isn't a coincidence that Jetpack Composer was born as Flutter was getting increasing adoption.

Except there is a big difference between Java/Kotlin and anything that uses NDK, outside graphics rendering, every OS API call on Android needs to go through either JNI or Android IPC.

Even if it is own special flavour of Java, with Kotlin toppings, and many love to bash it, because managed, the irony is that all the alternatives are much worse in device performance.

Mostly because NDK is only meant for games and native methods, so everything else needs to go through JNI all the time.

The problem with Google Pay in Germany, for me at least, is that it doesn't support many banks that my friends and I use. It's not normal for everyone to have a credit card here in Germany and I had to get one to be able to use GPay as well. In the meantime my bank built a crappy NFC payment app as well and told all customers to use this, while one iOS they support Apple Pay

I would love to see some sort of open payment protocol on android and iOS that banks would need to use, which might even have some special features like digital receipts etc

India did this with the United Payments Interface, and is it a thing of beauty. You can use any bank account, any payments app and pay to any other bank and any merchant. Ridiculously low interchange fee too since the backbone is managed by the central bank.

I thought most of Europe was on the path to adopting open banking APIs? How is this coming along?

So the Flutter rewrite wasn't that much of a clever decision after all.

For once, I actually love the new GPay app.

Reply on news.ycombinator.com