The Convoluted History of Google Payments
Description
This image is a flowchart diagram that visually maps out the complex and confusing evolution of Google's payment services from 2006 to the present. It starts with 'Google Checkout' (2006-2013) and shows how it, along with other services, evolved through various rebrands and mergers. The chart includes 'Google Wallet' (2011-2018), 'Android Pay' (2015-2018), and 'Tez' (2017-2018), all of which were eventually consolidated into different versions of 'Google Pay' and 'Google Pay Send' between 2018 and 2020. The final state shows a split again, with both 'Google Wallet' (2022-present) and 'Google Pay' (2020-present) coexisting. This diagram serves as a powerful visual critique of Google's notoriously chaotic product strategy, illustrating a real-world example of the brand confusion that frustrates users and developers alike. It's the punchline to the preceding Twitter thread, providing the evidence for the satirical commentary
Comments
7Comment deleted
Google's product strategy for payments looks less like a roadmap and more like a git history after a dozen developers tried to merge their feature branches at once without a rebase
If Google payments were a microservice, their Swagger file would hit the 1,000-line mark just tracking aliases
Somewhere at Google there's a principal engineer who's been maintaining the same payment processing backend through seven rebrandings, watching PMs rediscover "wallet" as a revolutionary concept every five years
Google's payment product strategy is the perfect example of eventual consistency - eventually, they'll figure out what to call it. This flowchart looks suspiciously like a microservices architecture diagram where each service was independently deployed without anyone checking if similar services already existed. At this point, Google's payment products have gone through more rebrandings than a legacy codebase has had 'final_final_v2_ACTUAL' commits. The real question is: do they have a feature flag system for product names, or is this just aggressive A/B testing at the organizational level?
Only Google could run two‑phase commit on a logo: prepare(Android Pay), commit(GPay), rollback(Wallet) - leaving our OAuth scopes in zombie state until the next rebrand
Nothing says “stable payments platform” like a family tree that reads like git rebase --force: every rename meant new OAuth scopes, SDK coordinates, and another PCI audit spreadsheet
Google payments: The canonical excuse to bolt on yet another adapter layer in your fintech monolith