On November 8, 2016, India’s prime minister, Narendra Modi, made an unscheduled and unprecedented announcement to the Union Council of Ministers and, later that night, on national TV: The country’s largest denominations of currency, ₹500 and ₹1,000, were being demonetized.
Overnight, in a country where over 95 percent of transactions happen in cash and banks remain largely inaccessible in rural areas, people and financial institutions were left scrambling to replace their useless notes with the limited supply of fresh currency. As basic transactions became difficult for the population at large, several technology companies started building mobile apps to meet their needs. These apps enabled peer-to-peer transactions on top of the Unified Payment Interface, a system launched by the government earlier that year which enabled real-time transfers between supported banks.
Google’s Tez was one of these apps. Already in development when demonetization happened, the Tez team pushed to launch ahead of schedule, in August 2017. Tez, which means “fast” in Hindi, would enable peer-to-peer transactions in India, and it would have to do it at Google scale from the get-go. “The app had to be universally accessible to everyone, on every phone,” says Mohit Kanwal, a senior software engineer who has led frontend development for Tez since its early days. Whether they used the rare, top-of-the-line iPhone or the popular, inexpensive Android devices with 1GB of RAM and 500MB of storage, no user could be left behind.
At the time, with the advent of these cheap and rudimentary Android devices, rural India was experiencing explosive growth in mobile internet users: the Internet and Mobile Association of India reports 26 percent year over year as opposed to 9 percent in urban areas, where the market was closer to saturation. For most of these new, rural users, mobile was their first experience with the internet. With no preconceived ideas and no previously established behavioral patterns, these users expected the internet to just work. “Users [who] are coming on to use phones, especially in the era of demonetization, are really picky,” Kanwal says. “They have high standards for what they feel like the app should do. Phone is internet, and the way they expect the internet to work on phones is seamless[ly].”
Among rural India’s mobile users, only 12 percent were women. Due to safety concerns, many women in both rural and urban settings remained hesitant to share any identifying information online, including phone numbers and bank details. (This is part of the reason why 60 to 65 percent of purchases made on e-commerce platforms in India use the “cash on delivery” payment option.) To work across demographics, any app the team built had to be intuitive—and any payment platform trustworthy.
The Tez team decided to build the app with two user personas in mind: working professionals who, as seasoned internet users, were more likely to be motivated by cash rewards like the app’s Friday scratch cards; and women and new internet users who were interested in managing their finances securely. Kanwal says 20 percent of their work involved finding the right engineering solution to connect any two devices. The remaining 80 percent went into the productionization of the solution, making sure it worked for both seasoned and new internet users.
“A lot of [payment apps at the time] were using QR codes,” Kanwal says. “The issue with QR codes is that you need a good camera, and some of [our users’] devices don’t [have one]. But they do have a microphone and a speaker.” So did many of the standard point-of-sale machines that accept payment by credit card in shops and restaurants. The team was intrigued by the idea of enabling payment transfers via audio transmissions as well as of creating a “Tez moment,” a digital handshake between two devices that would both facilitate peer-to-peer transactions in the wild and replicate the feel of cash transactions. Privacy was key: At no point during a transaction would a user’s full mobile number or bank details be shared with the recipient.
After a lot of testing in a custom lab outfitted with soundproof boxes to simulate audio interference between device pairings, their new technology—which they named Audio QR—seemed to work. “The accuracy of Audio QR was pretty low, but after a lot of rapid iterations, it increased up to 80–90 percent, to the point that you could have phones [seperated by] about one meter and still be able to scan them without any problems with interference,” Kanwal says.
Audio QR is a cross-platform library responsible for sending and receiving arbitrary bits of data over audio. Much like auth tokens in REST APIs, it sends audio tokens to the backend server for authentication. Kanwal says it’s then key to work with a modular frontend architecture. He describes their Android and iOS apps and merchant portals as clients, and the APIs that the client talks to as the frontend. Audio QR can be thought of as the bottommost infrastructure layer of the frontend because it interacts with the hardware in the Android or iOS client into which it’s integrated and which is its only responsibility. In well-defined and distinct modules, “your features are completely separate from the infrastructure layer,” Kanwal says. “You have to layer the frontend in a way that such a thing is possible.” On top of the Audio QR layer is the business logic, and on top of that are separate features. “That’s the only way such a big app can scale well.”
This kind of microservices-based frontend architecture is made possible by Dagger, a dependency injection framework for Android that allows the frontend team to work both together and in isolation. A developer working on an Audio QR feature can write their implementation and compile the rest of the app as if it were an API. The feature can then be tested against it. “In the final [Android application package], we then have a module that will stitch together a particular implementation of the Audio QR feature and the rest,” Kanwal says. “With Dagger, you don’t compile everything all the time, you just compile your own particular feature.” The rest of the app, he says, “you can stub out,” thereby streamlining work.
Tez serves users in eight widely spoken regional languages, and some users rely on audio alone to navigate the app due to varying levels of visual ability and literacy. As a result, accessibility testing is a key part of the production process. Engineers and QA specialists share responsibility for triaging accessibility issues through user acceptance tests.
Many of the requests Tez processes are critical for the user: A delay in rent payment could have dire consequences. The team works hard to prevent debilitating spikes in traffic, like the one the app experienced on launch day, when it saw 100 times the amount of traffic the team had provisioned servers for.
“Some of the problems we encountered that day were not totally solvable by just increasing the number of machines,” Kanwal shares. Users were experiencing long load times, and some had issues processing their first transaction. “It’s a bad user experience,” he explains. And because of that experience, “they’ll think it’s a bad app and uninstall it.”
“Having a scaling balance ensures that we are able to serve the traffic with milliseconds of processing time,” Kanwal says. “The code has to be written to make sure that whenever you scale machines, you can handle more traffic.”
Some traffic surges are expected, like when in-app scratch-off cards (where active users have a chance to win cash rewards) become available on Fridays, for which the team automatically scales their servers in preparation. And then there’s the hockey-stick user growth itself: Tez now has over 67 million monthly active users in India. They’ve handled this, Kanwal says, by writing efficient queries, sharding the database, and “splitting the frontend into multiple different, small frontends, like the notification frontend, app frontend, [and] merchant frontend, [which helps] to ensure our traffic graph is [nearly] completely flat.”
In 2018, Google rebranded Tez as Google Pay. The app has since expanded: To serve small businesses, Google Pay launched a merchant platform, and for P2P users, a chat feature that allows for a social experience within their app. To meet the needs of a wide swath of underserved users and build trust in a historically cash-run economy—indeed, the total amount of cash in circulation has increased every year since demonetization—ensuring a well-structured and efficient frontend has been essential to the app’s utility and success.
The aim of universal accessibility is to build for the spectrum of human abilities and resources. For that, Kanwal says, “You have to pause and think [about whether] what you are doing is actually beneficial. We must ship products that [come] close to working for everybody.”