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

Notes:

** 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