Engineering @Zeta

Buy Now Pay Later: The Real Deal or Just Hype

In our previous blog (BNPL — The Modern Day Credit Card), we compared buy now pay later to traditional credit cards. We compared the two products and spoke about the different types of buy now pay later offered to customers. But, is buy now pay later all it is made out to be or is it just a flash in the pan?

Global Market

Globally, providers such as Klarna, Afterpay, and Affirm have paved the way for the buy now pay later ecosystem. In 2019, buy now pay later had a global market size of US$7.3 billion. Coherent Market Insights, expected it to grow to US$33.6 billion by 2027 at a CAGR of 21.2%.

While Australia and Sweden were the top markets a few years back, the buy now pay later trend has caught on in the UK and the US.

Worldpay suggests that buy now pay later spending in the UK would rise from £9.6 billion in 2020 to £26.4 billion in 2024. According to Fobes, Americans made $20 billion worth of purchases using BNPL programs in 2019 and will spend $24 billion on products and services using a BNPL service in 2020.


Key Metrics


  • Operations in Australia, USA, UK, New Zealand.
  • 7.3 Million users.
  • Major Market: USA
  • Market Cap: $17.7BN


  • Operations in 15 countries.
  • Market Cap: $33BN


  • Operations in USA & CANADA
  • Market Cap: $16.73 Bn

Indian Market

The trends are similar in India. Businesswire expects the buy now pay later payment adoption to grow steadily between 2021 and 2028, recording a CAGR of 24.2%. It expects the gross merchandise value in India to increase from US$ 6.990.5 million in 2020 to US$ 52827.2 million by 2028.

Buy now pay later is offered by multiple companies in India. LazyPay, ZestMoney, and Simpl are few of the pure buy now pay later companies. Other e-commerce companies such as Amazon and Flipkart, wallet providers such as Paytm and Mobikwik, banks such as ICICI and HDFC, and payment gateways such as Razorpay offer this as an option to their customers.


Key Metrics


  • 4 million active users.
  • 2 million transactions per month (December 2020).
  • 250+ merchant base.


  • 6 million registered users in (February 2020).
  • Average transaction: Rs. 12,000/-
  • Tie-up with 15,000+ merchants.

Flipkart PayLater

  • 65 million existing Flipkart users.
  • Active on Flipkart, Myntra and 2Gud.
  • Focuses on customers tier 2 and tier 3 cities.

Paytm Postpaid

  • 7 million users (November 2020).
  • Tie-up with 5 lakh+ merchants.

ICICI PayLater

  • Available only to ICICI Bank customers on ICICI platforms such as Pockets, iMobile App, and their bank website.
  • Default payment option Razorpay buy now pay later customers.

Bajaj Finserv

  • Available all over India.
  • Available in offline and online stores.
  • 8000+ stores online stores
  • 1 lakh+ offline stores in 1900+ cities


  • Provides buy now pay later via POS machines
  • Has 95% of the offline buy now pay later market share.
  • 30 million users.
  • Tie-up with 1.5 lakh merchants.

Here to Stay

Buy now pay later is an attractive offering from financial institutions. In 2020, buy now pay later accounted for 2.1% of ecommerce transactions worldwide, according to Worldpay. This number is expected to double by 2024.

In India, buy now pay later grew over 30% in 2019. According to a survey conducted by ZestMoney in 2020, 60% of women surveyed said they would use buy now pay later and 51% said they prefer it over credit cards.

Security Principles for Mobile Applications

The challenge when building a secure mobile application is how we balance ease of use with security. Applications that are easy to use are the ones that succeed. However, any compromise on security could have disastrous consequences. Mobile applications that handle payments have more stringent security protocols when compared to utility applications. However, to succeed, it has to be just as easy to use.

These were the topics of discussion at Rootconf’s Data Privacy Conference held in April 2021. The roundtable, moderated by Suman Kar, included Madhusudhan Sambojhu from, Chirayu Desai from Calyx Institute, and Apurva Jaiswal, Engineering Manager at Zeta.

Zeta develops cloud-native mobile-first banking and payment platforms that meet these exact requirements. We aim to move away from lengthy checkout forms and OTP-based payment authorization. Our platform allows merchants to securely accept payments from around the world and allows customers to make these payments with a single swipe.

Let us discuss some of the security principles we follow at Zeta when designing our mobile applications.

Zero-trust Principle

Adopting a zero-trust approach is important when it comes to securing data on applications. Organizations building the application should ensure they have implemented all necessary security measures to protect user data. They should not depend on the application hosts for this.

There are 2 types of data that we need to secure in mobile applications:

  • Data at rest.
  • Data at motion.

All sensitive data should be saved in vault storage and should be accessible with explicit consent from the user.

Since mobile devices are sandboxed from day one, it helps protect application data, stored on the device’s internal storage, from hackers and other applications on the device. Some tools that can be used to secure data are Charles proxy, Wireshark, Firebase, and SonarQube.

[su_youtube_advanced url=”” autoplay=”no”]

At Zeta, we ensure user data is opaque to the cloud provided and is end-to-end protected. We distill and sanitize the network edges. We ensure end-to-end authentication and access control using IAM and RBAC.

Listed below are some best practices we have adopted at Zeta when building mobile applications.

Mobile Application Security

Mobile application security is the measures taken by the application developer to secure the applications from external threats. A breach in mobile security gives hackers access to the user’s personal information, their current location, banking information, and much more. Some best practices are:

  • Perform root checks using Google SafetyNet API and Rootbeer. On iOS devices check for functions that should not be available in a non-rooted device.
  • Use SSL Pinning to prevent attackers from analyzing your application functionality and the way it communicates with the server.
  • Build strong and customizable authentication flows: — Phone number + OTP, Phone number + OTP + password
  • Do not allow concurrent logins.
  • Analyze user behavior and trigger re-authentication in case of risks.
  • Have a strong device binding ID (Device ID + Sim ID)
  • Do not issue tokens when the device binding ID changes.
  • Server triggered data wipeout.
  • Screen record and screen capture protection.
  • Launcher image protection.

APK Security

It is not enough to secure your application while it is being used. It is critical to ensure your application is hosted and distributed from a secure platform. This prevents hackers from gaining access to your code repository and exploiting it to gain unauthorized access to user data. Some best practices are:

  • Never distribute APKs through APK/IPA files. Use standard firebase app distribution/testflight.
  • Never release debug builds.
  • Assume whatever goes in APK is public information :- The Native Development Kit (NDK), Prefer server-side secrets
  • Implement code obfuscation.
  • Incorporate proguard rules in your builds.

Identity Establishment and Authentication

When onboarding a customer on your mobile application, it is important to establish their identity. This allows us to ensure only that person has access to the application on their device. Some best practices are:

  • Challenge a user using multiple identity vectors such as phone number, email, bank account number, and password. Challenges should be sent on different communication channels
  • Each vector is identified by a specific IdP.
  • Implement Social Authentication.
  • Use penny testing to verify a user’s account.
  • Successful authentication leads to a 256 bit AES symmetric key between server and client using ECDHE-ECDSA-AES256 bit key exchange.
  • Subsequent device sessions are established using OATH-based HOTP of monotonically increasing session count.
  • 256 bit Symmetric Keys.
  • OATH-based HOTP for authentication.
  • Key setup using ECDHE-ECDSA-AES256 bit.
  • Real-time locating system (RTLS) optimized transport based on TLS 1.2. : — Key exchange through ECDHE-ECDSA-AES256 bit key (Equivalent to RSA 372 bit), Encryption, authentication, and integrity check through AES 128 bit in counter mode with SHA-256 based HMAC.


Securing transaction data is the most important aspect of mobile security. Any vulnerabilities here can lead to the application user losing money and cause irrevocable setbacks to your application.

  • Non-repudiable transactions.
  • Private keys protected using Secure Module on Device or Password+Scrypt.
  • Non-verifiable random key material on the device.
  • Key rotation after every successful online transaction.

Assume the mobile application code/library is public

This should be the basic assumption an organization makes when building a mobile application. To ensure there are no compromises to an application’s security, organizations need:

  • Ensure their mobile team is kept up to date with and implements the latest security guidelines and practices in the industry.
  • Ensure all security checks and protocols are enforced when deploying code.
  • Have their mobile application regularly audited by external auditors.

[su_youtube url=””]

At zeta, we believe in building and nurturing a strong team that understands security and follows the importance of:

  • Code peer reviews.
  • Static application security testing.
  • Regular security testing team by Zeta’s internal security team.
  • Regular application security testing by 3rd party vendors such as SISA.


There cannot be any compromise in terms of security when building mobile applications. Apart from setting up security protocols, organizations should ensure their employees are kept up to date with the latest trends in security. Organizations can use tools to enforce security protocol and ensure their applications are secure.

It is also important to educate end-users about best practices around mobile applications. Users should only download applications from trusted application hosts. Downloading applications directly from a website or elsewhere could lead to security breaches.

Zeta Suite is rethinking payments from core to the edge, algorithms to form factors, applications to solutions. Having built a modern stack that Financial Institutions (FIs) can use for debit, credit, and prepaid cards, loans, authentication, and Fraud and Risk Management (FRM), Zeta invites you to join their journey in democratizing payments. Check out the openings on < >


Wallet 2.0

Wallets are the most basic thing a person has had since early times. We needed something to put our money in clusters for our daily utilities, one cannot access an ATM for every single time of purchase. Now, a digital version of it came called e-wallet, which can provide aggregation capability for payment-related instruments for ease of use, which allow customers to pay for purchases digitally.

Wallet 1.0

Let’s discuss a basic model of Wallet 1.0. It provides an aggregation over a bunch of supercards and accounts. Supercards are the debit or credit cards managed by Zeta and can be either physical or virtual.

The wallet is also associated with accounts (or cloud cards), some of the examples of cloud cards include meal cards, cash cards, and communication cards, which you can see in the Zeta app. Debit or credit occurs at these accounting instruments, and these accounts are hosted in the Aura** domain for Wallet 1.0.

Coming to the payment plan generation, when any transaction is initiated by the customer using their Super card, first, the wallet linked with the super card is identified. Now, let’s say there are three accounts that are linked with the wallet: meal, communication, and cash card. Consider a case where we initiate a transaction for 100 bucks using a Supercard at Mcdonald’s. First, the wallet linked to the Supercard is identified. For that wallet, let’s say, there are three accounts linked: — corresponding to the cash, communication, and meal card. To identify which of a user’s account to debit, by how much and in which order, wallet generates a payment plan. On the basis of various parameters in the incoming payment request and the applicable account selection rules, eligible accounts are filtered. Some reasons why an account can be filtered out include: exceeding the max daily or monthly spend limit, exceeding the max transaction limit or payment may only allow a particular currency account to be used. In our example, let’s say due to certain restrictions, the communications type account was filtered out.

After this filtering, the accounts are ordered on the basis of the suggestion strategy. This ordering decides how one or more accounts are to be debited for the payment. So, while purchasing food items, it might be preferable to debit the meal card first and then debit the remaining balance (if required) from the cash card. So, for the transaction at Mcdonald’s, in case our meal card does not contain sufficient funds, the generated plan may suggest something like debit $90 from the meal account and $10 from the cash account.

Once this is done, a final ordered sequence of accounts, along with the proposed debit amount, is presented to the payment engine, which further acts based on this plan.

Why Wallet 2.0?

  • Wallet is an aggregator of supercards only rather than a generic pool of payment instruments
  • Violating separation of concerns
  • Wallet shouldn’t be responsible for aggregating payment instruments
  • Wallet is performing payment instrument authentication
  • Wallet’s payment accounts are only from Aura** domain
  • Wallet is tightly coupled with #Zetauser
  • No wallet product specification exists

Wallet 2.0 Design

A wallet product acts as an umbrella or specification for a wallet which is a materialization of the wallet product and inherits its properties from the product.

The definition of wallet product provides the capability to manage wallets — their selection rules, suggestion strategies, and other flags and attributes at a top-level.

Similarly, a payment account product governs the definition/schema for payment accounts. Each payment account product is linked with a payment account provider which acts as an interface to the actual account provider (like Google Pay/ PayTm).

We can perform operations such as to get account balance for example through this interface.

Coming to the payment side of the picture, let’s say the user in BigBasket is saving a VISA card, a corresponding payment account would be created for it. Then, he/she adds another MasterCard, corresponding payment account would be created and added. The Payment Account Product here could be modeled as payment types such as VISA and MasterCard as the semantics of authentication and transaction workflow depends on these. Now, for a VISA payment account, when say get balance is needed, it would reach out to the Payment Account Provider which could be Aura if we are maintaining the account here at Zeta or Shadowcard which would reach out to the VISA network to get the balance (detailed example).

Now, having all things together, when BigBasket asks for a payment suggestion for a user, the configured selection rules and suggestion strategies are applied for that wallet’s payment accounts while taking the help of Payment Account Providers in order to generate the payment plan which can be passed back to BigBasket.

Thank you


** Aura cluster is the core digital accounting system also termed as the heart of the financial systems of Zeta. Any financial transaction to be effected would be accounted for and recorded in Aura. It helps to keep track and manage the financial information of Zeta’s Business Clients. Aura has the ultimate authority in approving/rejecting a financial transaction.

Speakers — Siddharth Sharma & Praveen K L

Edited by Phani Marupaka

Tuning Cipher to 1M TPS for ease of scaling of online authentications (Part 2)

We went through the overall idea behind the demo in Part 1. Part 2 will inform us about how we achieved the feat, highlighting the technologies that we used along the way. Heads up, it is going to be engineering focussed. 

Quick recap: Cipher demonstrated the successful handling of a chart-busting 1 Million Transactions Per Second of online authentication requests utilizing a prudent cost of $200/hour of AWS cloud infrastructure. The simulated authentications are 240x higher than the authentication output put together by all of the big players in India during online payment transactions. 

Things we did engineered a nutshell

  1. Optimized systems for a minimum unit for processing a desirable number of online authentications 
  1. Built the infrastructure 
  2. Setup the simulation environment and node distribution mechanisms
  3. Processed successful authentications for the transactions
  4. Scaled the minimum unit for the desired load capacity of 1 Million TPS

Infrastructure used

  • Nginx – A web server used as an ingress controller (to accept HTTP requests).
  • EKS (Elastic Kubernetes Service) – An AWS managed service to run Kubernetes.
  • Prometheus – An open-source monitoring system with a dimensional data model, flexible query language, efficient time-series database, and modern alerting approach.
  • Grafana – An open-source analytics & monitoring solution for databases and microservices.
  • Metrics server – A cluster-wide aggregator of resource usage data for auto-scaling horizontal pods. 
  • Microservices
    • Edith
    • Cerberus
    • MasterCard Cipher
    • We’ve presented JVM stats, HTTP requests & connection stats from each of these apps via metrics endpoint and made this a scrape target in Prometheus.
    • We’ve also enabled the JMX port on each of these microservices to monitor them in real-time.

Node distribution

‘Node’ is a container of a single server where multiple microservices can be run and monitored to successfully process a definite amount of authentication requests. We configured each of these nodes at 64GB RAM & 16 GB processor and deployed them on Kubernetes. 

Each node had several pods running within it, which hosted the microservices required for authenticating online transactions. Amongst the microservices, there are three notable ones. 

  1. Mastercard Connector – To handle the ACS protocol specific nuances and serve as a connector for the Mastercard card scheme
  2. Edith – To orchestrate the intricate authentication plans
  3. Cerberus – To serve as the Identity Provider and the core authentication engine

Simulation environment

Although processing 1 Million TPS was the objective, we also had to generate that much amount of transaction load for doing that. So, we used Gatling as the load generator. We let the Gatling Master spread across four zones, spread across in Mumbai and Singapore, for running 50 tasks of individual test scripts to authenticate bank transactions coming in from card networks. 

The Gatling injector simulated the interactions that a card network usually has with its ACS provider while authenticating online transactions. It also reproduced the cardholder interactions required for authentication. The system-level simulations are – 

  1. VEReqs on behalf of the card network
  2. PAReqs on behalf of the card network
  3. Challenge-response submissions as performed by cardholders to prove their authenticity

The simulator routed these requests to auto-scalable clusters of Cipher microservices, which were configured with dummy BINs. 

Authentication flow

These are the steps for a successful authentication flow. 

  1. The simulator verifies (with VEReq) if the card under authentication is enrolled with Cipher. If it is, the simulator initiates the pair authentication request (PAReq) and gets the authentication URL from Cipher.
  2. Gatling simulates the Swipe to Pay (S2P) interaction, generating the necessary credentials required for completing the authentication. 
  3. Gatling submits the S2P challenge and receives the authentication response.
  4. It redirects the control back to the card network module that’s simulated.

Minimum unit

A minimum unit consisted of a specific number of instances of every microservice. The function of this minimum unit was to handle a definite number of transactions. 

To come up with this unit, we tested each microservice individually to get a measure of the number of authentication requests it could serve in a given time period with specific resources allocated to it. The minimum unit that we came up with successfully handled 20K authentication requests.

1 minimum unit = 3 units of Edith, 2 units of Mastercard Connector, 2 units of Cerberus

Here is the resource utilization data when Cipher was comfortably serving 20K authentications. 

Scaling of the minimum unit

Now that we had a stable unit that could serve 20K TPS comfortably, we scaled it to accommodate additional authentication requests. We used this unit as the base reference for serving transaction requests from one issuer. 

With this logic in place, we scaled the minimum unit up to 50 such units, handling 20K TPS each, to serve 50 issuers, leading up to 1 Million TPS. The 4 Gatling servers simulated the load for 500 distinct BINs spread across 50 issuers, each having 1,00,000 cards. The entire setup, consisting of 4 Kubernetes clusters, spanned across 2 AWS regions with two availability zones, respectively.

With AWS, the nodes aren’t scalable within minutes. But since we had to attain that, we warmed up the nodes by scaling up the pods. We used 350 of the pods within 100 nodes to handle the heavy load of 1 Million authentication requests. When the load was less, we scaled down the nodes by cutting down the pods based on the resource utilization factors using Horizontal Pod Autoscaler. 


  1. The authentication’s write I/O was done asynchronously considering the purpose of the live demonstration.
  2. Three requests effectively make one authentication.

If you’d like to check out the test data that we used for simulating authentications, it is available for reference here.


It took our team of 8 people only 9 days to successfully deliver the desired results. We’re glad to have made some key decisions during this process that allowed us to quickly achieve what we wanted – like choosing AWS, Kubernetes, and Gatling Enterprise. We hope to work on several such innovative initiatives that redefine the future of payments in our country and beyond. Thanks for reading and hope you found this helpful!


Developers who made this feat possible – Mrinal Trivedi, Amit Raj, Ramki, Dipit Grover, Amit G, Shubham Jha, Vivekanand G, Mohd. Tanveer, Shaik Idris

Author – Preethi Shreeya, Phani Marupaka

Achieving 1 Million TPS with Zeta’s Cipher – A new benchmark in the Payments Industry (Part 1)


We marked 22nd Jan 2020 as a historical day of significance for Zeta and the future of payments! We were able to successfully showcase 1 Million Transactions per Second (1M TPS), illustrating the scalability and elasticity with which banks can handle online transactions.


In December 2019, we launched Cipher, a cloud-based Authentication as a Service solution that provides an easy way for the issuing banks to participate in online transactions, adhering to the 3D-Secure protocol as laid down by EMV Co. 

With Cipher, the issuing banks can provide modern, cutting-edge, and secure card authentication services to their cardholders. To unveil the robustness of the service, i.e., the amount of authentication load that can be handled at the highest success rate (99.9%), we planned to simulate 1 million online authentications. 

To put things in context, currently, the maximum online transaction volume across India is approximately 4160 per second, considering the transactions processed across all of the electronic payment channels like UPI, Visa, Mastercard, Rupay, NEFT, and IMPS. You can find the reference calculation here

When we say Cipher can handle 1 million authentication requests, it is 240 times more than the number of payments being processed in India by all of the big players put together.  

This estimate gives us an idea of the incomparable scale at which Cipher can handle authentications, relieving issuers and merchants from the persistent problems of scalability and reliability during flash sales and other peak load scenarios. Besides, We have built Cipher in such a way that it is elastic, so no resource gets wasted. When there is an increase in the request volume, the systems self-provision the resources from cloud providers and relinquish the same when the request volume decreases.


Why is this important to us? The first reason is that we want to enable issuers to authenticate as many transactions as possible, with the highest success rate and reduced revenue loss. Naturally, issuers will be able to handle any amount of eCommerce sales at all scales that merchants can imagine. When Cipher can do all of the heavy liftings when it comes to online authentications, issuers have the comfort of focusing on their core bank offerings rather than worrying about server overload and authentication failures.

The second reason is more personal. We want to convey that ‘scale’ is a solved problem with Zeta. As more and more commerce progresses online, it is natural to expect that the payment authentication solutions will run at this internet-scale. 

We believe that all of the consumer-facing banking and payment services should be as scalable as Google Search at peak loads. We want to exemplify this with our Cipher demonstration. We want to assure the banks that they don’t have to worry about scale anymore.  

Demo Details

In the dashboard, the number on the left indicates authentication requests being handled by Cipher in reqps. The middle number shows the maximum number of requests at the current computing capacity in the selected time window (5 minutes). Towards the right, we have the number of pods (systems) of Cipher that are up and running to handle the required load. In the central region, we have the success rate of the authentication requests.

As one can notice, during the video

  1. The number of requests handled per second increases from 18 reqps to 1 Million reqps in about 3 minutes.
  2. The success rate of handling the authentication requests stays constant at 100% throughout the demo.
  3. When the load is lightened, the number of computing pods required for handling 1 Million TPS shrinks back to a smaller number showcasing how Cipher auto-scales.

As Cipher’s systems are horizontally scalable, they are limited by the computing and storage units built into them. So, by any means, this high load of 1 million TPS does not indicate the maximum ‘capacity’ of the systems. Cipher can extend to the internet-scale and shrink to a single node footprint, based on the needs. We think we demonstrated that alright. 🙂 

Scope Inclusions

In the above demonstration, we have simulated:

  • Mastercard Card Network to demonstrate the authentication initiation requests (as per the 3DS authentication protocol) that get dispatched to the Cipher system.
  • Swipe2pay authentications – to simulate user engagement while fulfilling the authenticating challenges.

Scope Exclusions

  • User interactions for authentications to do away with the additional time
  • Risk and fraud checks

Key metrics

  1. Resources used (Cipher)
    1. Units: 350 server instances (all microservices incl.); (Kube cluster running on 200 m5.xlarge EC2 instances)
    2. Memory: 8 * 360 GBs
    3. CPU: 4 * 360 vCPUs
    4. Bandwidth (if available)
  2. Resources used (Load Generator)
    1. Units: 50 * c5.4xlarge EC2 instances
    2. Memory: 32 * 50 GBs
    3. CPU: 16 * 50 vCPU
    4. Bandwidth (if available)
  3. Verification mechanism used
    1. JSON web signature.
  4. Test Data Structure
    1. Banks: 50
    2. Card BINs: 500
    3. Cards per BIN: 10000
  5. Average response time per request: 100ms
  6. Hops per each request within Cipher cluster: 
    1. VEReq: 1 hop
    2. PAReq: 2 hops
    3. Submit Swipe2Pay challenge: 3hops 


We honestly believe that the 1 million TPS demonstration has set a new benchmark for payment authentication solutions. We are also delighted that we were able to pull this off in a short period of 9 days. Although we didn’t have enough time to explore a lot of other frameworks for additional optimizations, we think we did great in the time we had! 

It’s also worth mentioning that our systems are capable of scaling more than 1 Million TPS when necessary. We hope that cloud technologies get widely adopted by issuers in the Payments Industry to be able to improve their offerings for their customers significantly.

We have a part two which delves into the core engineering aspects of the demo for the relevant audience. Thank you!

Part 2 of the blog


Developers who made this feat possible – Mrinal Trivedi, Amit Raj, Ramki, Dipit Grover, Amit G, Shubham Jha, Vivekanand G, Mohd. Tanveer, Shaik Idris

Author – Preethi Shreeya, Phani Marupaka

SecureShield: Campaign for Secure Transactions

As Indians, we are desensitized to certain social evils. Corruption. Dowry. Black Money. We see them often, and yet we may not really process them, until they injure us or our loved ones directly. I feel there’s another social evil, one that’s heavily hushed and downplayed by the industry and media: terrible practices in electronic payment security.

When I talk about this to my friends who use cards, I see the same level of indifference one might see about corruption. But once in awhile, I talk to someone who had to request a chargeback. Their story, of course, is very different. They quickly relate the pain of investigative questions that they were subjected to and the countless, diligent follow-ups they had to make before the money reappeared in their account. And it is far worse if they’d been travelling or if that was the only money they had.

At Zeta, we take security very seriously. We don’t allow users to add money to their Zeta account without a second-factor authentication (usually, OTP sent by the user’s bank like ICICI or SBI). And yet, every day, we get half a dozen messages from our users telling us that someone cheated them of their PIN, OTP and card details, charged their cards and added funds to some Zeta account. We process dozens of chargeback requests a day.

Honestly, far more people pay using cards than the number of people who use Zeta. If we see so many cases of card payment fraud on a daily basis, we can only imagine how many people lose money every day because of this.

In my previous post on payment security, I have described in detail card payment insecurities and how the prevailing practices are fundamentally flawed. For example, it is not uncommon for banks to say the following:


But every user knows that they cannot do a card transaction online or at a store without giving the card or card information to the merchant. The user has limited control over where he is entering the PIN, OTP or other details.

This must change. By default, users should have secure transactions. Nothing that the user is asked to share should make him vulnerable to fraud.

We built Zeta Super Card with this fundamental rule. We have now made it available for everyone.

Zeta Super Card with SecureShield

Zeta Super Card is a prepaid card that you can load at your will. It is available in digital form the moment you install our Android or iOS apps. You can request for a plastic card on our website or through our apps. You can use this card online for eCommerce transactions or at any stores with a swipe machine that accepts MasterCard. Although it can work at any card accepting merchant as any normal debit or credit card, it is the SecureShield feature of the Super Card that makes it incomparably more secure than traditional magnetic stripe or chip cards with PIN.



With SecureShield we have brought security into your hands and delivered unprecedented controls that prevent card frauds without compromising your convenience. It acts like a remote control for your card.You can turn your cards on and off anytime. When the card is off, no transactions will go through! You can turn it on whenever you want to pay.



You can use dynamic SuperPIN in place of traditional 4 digit PINs. This ensures that even if the waiter at the restaurant speaks/shouts out your PIN or a CCTV camera watched you enter the PIN, you needn’t be worried. SuperPIN is valid only for 2 minutes and exactly for one transaction. SuperPIN will be available on your phone even when you are offline. You can safely transact any time at all shops that accept cards.




With LocationShield on, you can be sure that no fraudster can transact using your card details even if you inadvertently shared them over phone or email. The system will allow transaction only from machines close to you. If you are in Bangalore and if a fraudster in Mumbai gets your card details and OTP or PIN, he will still not be able to transact using them unless he is also in Bangalore. Irrespective of whether the fraudster is trying to do an e-commerce transaction or doing a transaction with skimmed card on a POS terminal, the transaction will be rejected and you will be notified!


If you transact on ecommerce sites, you would be happy to know that you need not wait for OTP and enter your passwords. By now, you might know the vulnerabilities in that process. With Swipe2Pay, you just need to swipe on the secure dialog presented by Zeta on your phone to complete ecommerce transactions. It is fast, convenient and insanely secure.

Traditional PIN

If you still want to use a traditional 4 digit PIN, you can do so with an increased level of security offered by quick and instant PIN change mechanism available in your app.


secureshieldTracking Score

The SecureSheild also keeps track of the security strength of your settings. You can tweak them as you like and know how secure your card is, at any point in time.

Some of these security features are firsts of their kind in the world. But more importantly, they are made to be friendly and easy-to-use, not only for people like our friends but for people like our parents and grandparents, who are not technically inclined.

You must start using Zeta Super Card over any other card if you care for the safety of your funds. You should also give it to your mom, dad, grandparents or anyone else whose financial security you care about. Get your cards today!

Join the campaign of secure electronic transactions! #SecurityFirst @ZetaIndia

Today, Payments are generally insecure

Have you ever been asked by a waiter at a restaurant for your card PIN? Has he ever written it down on a piece of paper? Have you ever noticed a CCTV camera watching you enter the PIN at a shop? Have you ever used an app to buy something, and got redirected to your bank’s web page to enter the PIN? Have you ever given permission to an app to read all your SMS messages, some of which may contain payment OTPs? 

By now, you might have guessed that your PIN and OTPs are easily compromised.

The many technological advancements since the time card based payment systems were introduced have made the systems defenseless. Fundamentally, card based systems require every machine and all intermediaries involved in the transaction to be secure. There are way too many of those machines and intermediaries across the world to ascertain security of them. Many people who use those machines, like merchants, have little idea about their role in securing the entire system. Any breach at any one machine can cause unrecoverable damage to several users. The card details once captured can be reused several times for many transactions.

To overcome some of the limitations of the payment cards, a PIN is mandated for every transaction. A 4 digit PIN offers protection against many trivial threats. But given the reusable nature of the PIN and also the poor choice of PIN made by users, it is not a strong enough defense.

It is hard for the user to know if the card machine at a retail store or the ATM on which she is entering the PIN is tampered with. Banks providing these machines can’t practically keep a watch, as several machines are deployed in unmonitored physical environments.

In case of personal devices like phones, users will have far better visibility and control on tampering. However, most of these devices and the software that’s running on them are also vulnerable to a range of threats. Android users can easily notice that many programs can read the SMS messages on their phone. These programs can also export the OTPs in messages to a fraudster’s machine without user’s knowledge. Also, almost all mobile apps that accept card and netbanking payments can read and store the passwords, OTPs and PINs entered by the user. It may appear to the user that she is entering the PIN on the bank’s payment page. It is nearly impossible for the user to know if her password or PIN is captured and stored by the app.

It is not easy to trace the fraud back to the fraudulent app or merchant. The information captured by one app can be used by anyone from anywhere in the world. If one ATM is compromised, the cards used on that machine can be replicated and used on any other ATM. These vulnerabilities are just the low hanging targets for a fraudster.

To overcome vulnerabilities in operating systems, applications, hardware components and to defend against powerful machines and programs that can exploit the minutest of the vulnerabilities, it is essential to make security a foundational aspect of the system. The payment system providers should be fanatic about security.

Secure Foundation for a Modern Payment System

When we started work on Zeta in April 2015, we had the opportunity to consider a great expanse of devices and applications the modern connected world is currently using and is likely to use. We studied the state of the art secure protocols, services and algorithms and designed several core components of our payment system quite differently from that of legacy bank or card systems. We spent the first 3 months of our time in arriving at a secure architecture at the core. We used asymmetric encryption and signature algorithms to defend our systems against large scale fraud.

We arrived at the following ground rules to secure transactions against many of today’s threats:

  • 3rd party devices: System should not rely on any non-personal devices of the user for transaction security. The card reading machines, POS machines, ATMs or any other machines that don’t belong to either the transacting user or zeta should be assumed as vulnerable.
  • User provided data: Users are prone to use easily retrievable personal data for passwords, pins or for such other key material. System should not solely rely on such information to secure transactions.
  • Data Persistence and Transmission: Every transaction must require information that is never persisted on any device involved in the transaction. Information transmitted for a transaction should not be reusable to do any other transaction.
  • Visible Information: If information is visible to user, we assume that it can be shared or can be stolen through techniques like social engineering. No data the user may be able to share during the course of a transaction or otherwise should be sufficient to do a new transaction.
  • Data Location: No amount of data at rest on any one machine, or if possible in any one location (data center), should be sufficient to complete a transaction
  • Hardware Security Modules: Always use hardware security modules to secure the key material. On users’ devices that don’t support access to secure elements, use encrypted stores for key material.
  • Channel Sensitivity: System should strive to use the highest entropy algorithms and keys suitable for each transaction channel.

These rules guide the protocols and algorithms we use on Zeta. They influence many user interactions on our mobile and web applications as well.

Securing Card Payments

We provide Super Cards to many of our users. These are traditional plastic cards with magnetic stripe, provided to make payments to millions of card accepting merchants. This is our approach to make Zeta backward compatible with the present day payment systems. However, we didn’t want to limit ourselves to the insecure practices widely prevalent across industry. Using the ground rules discussed, we have adopted a different security model for Super Card transactions.

In-Store Payments


Dynamic OTP on the phone can be used as PIN

When a user transacts using his Super Card at a retail store, instead of a 4 digit static PIN, she can use the dynamically generated Zeta Code as her PIN. Using the Zeta Code ensures that even if the card reading machine or any of the intermediaries are compromised, no fraudulent party can make use of the PIN for another transaction.  

Online Payments

Zeta SecureCode Page    img_20161023_114134_700

User need not enter OTP for online payments

When a user starts a payment on an ecommerce website, she will be greeted by our custom SecureCode* page. Parallely, she is prompted with a dialog on her phone with an option to ‘swipe to pay’. If the user wants to confirm the payment, she swipes the slider on the screen and enters her PIN through a custom secure keyboard provided on the phone.  The payment page on the browser proceeds to the merchant website with payment success. The user wouldn’t have entered any input on the SecureCode page in the browser. As the user need not read and enter the input, we can now use significantly more secure algorithms like digital signatures to represent authorisation for the payment. This approach also offers a better user experience and quicker payment completion.

If the user is offline on her phone when she is on our SecureCode page, she can generate a Zeta Code on her phone and enter that on the SecureCode page. Each such 9 digit Zeta Code is valid only for 2 minutes. This eliminates the need for static passwords, PINs and SMS messages and thus their vulnerabilities.

Security in Mobile App Interactions

We believe relying on user’s personal device is better for security than relying on any 3rd-party device.  However, it is important to defend the information on the device not only against the possible loopholes of the hardware and the software, but also from the user’s ignorance. Failing to do so could allow for exploits in the form of malware and social engineering.

Therefore, when defining the security model of Zeta apps we assumed that on users’ phones:

  1. Keyboards are compromised
  2. SMSes are compromised
  3. Data at rest is vulnerable
    (Even though stored in application specific stored provided by OS)
  4. Text labels on the screen are compromised

We built a model that can maintain security and integrity of the transaction against such compromised components. A specific example is the Zeta code that is generated on phone to make a payment.

img_20161023_120833_837     img_20161023_121133_893

  1. To generate a Zeta code, user has to press and hold on an area on the screen until a ring is fully drawn.
  2. When the device is online, the code is generated against a digitally signed request from the user. We use ECDSA to achieve reliable encryption strength.
  3. The private keys used for signing the code generation request are encrypted and stored on disk. On phones that don’t have a secure element backed user authentication mechanism, the encryption key is derived from user’s PIN. On phones that have a secure element on, the keys are generated using high entropy sources available on phone and are stored in a secure element backed storage+.
  4. When we ask for PIN, we take user input through a custom keyboard that obfuscates every key press. The labels of the on-screen keyboard do not represent the actual data captured on each key press. Thus, the PIN of the user is virtually never captured in the form user remembers or reproduces it. Also, the derived input from those key presses never leaves the phone. 
  5. Once the code is fetched from the server, although the code appears like text, it is rendered on screen as an image. No malware or screen reader in the device will be able to trivially parse the text on the screen. 

Summing up the Card Payment Security

We must acknowledge that the card based payments can be made significantly more secure than how they currently are. MasterCard, Visa and Rupay have provisions for better security, but many of the prevailing implementations do not make good use of these provisions. We hope all of the industry players will adopt more secure options in the wake of the recently observed 3.2 million debit card compromise.

Although the recent breach is related to in-store and ATM transactions, we also hope that it serves as a wake-up call to reconsider some of the insecure practices related to online card payments as well.

We must constantly strive to earn the confidence that our users place in us. In the payment industry, it is extremely hard to win back a user’s trust after it is lost. We at Zeta will be happy to help everyone in the industry in this endless and rewarding journey of building and running secure payment systems.

* SecureCode is a trademark of MasterCard.
+ Our Android/Windows apps currently do not recognise secure element. The data is protected using keys derived from user’s PIN.