A behind the scenes look at the next UPI like revolution from India
Over the past decade, we’ve witnessed a remarkable transformation in India, transitioning from traditional methods to a digital economy, thanks to milestones like the introduction of Aadhar. The COVID-19 pandemic further accelerated this shift, driving us towards a more digital-centric existence, which has proven to be a significant improvement. If you’ve been even remotely connected to the world, you can’t help but acknowledge the transformative impact of the Unified Payment Interface (UPI) in our lives. UPI singlehandedly propelled us into the realm of being the world’s largest digital payments nation.
While much has been discussed regarding UPI’s architecture, scale, and economic significance, we are left pondering: What’s on the horizon for India? In this discussion, we will explore the potential for the next major digital revolution in India. Just as UPI revolutionised payments, a similar transformation could be in store for e-commerce through the Open Network for Digital Commerce (ONDC). While I don’t possess the intention or expertise to delve into its economic impact, what captivates me is the underlying technology that could facilitate this impending shift. ONDC represents a visionary network proposal built on the foundation of an open specification known as Beckn, and it holds the promise of reshaping the digital landscape in India.
The Beckn protocol represents a comprehensive suite of specifications encompassing APIs, data models, reference architecture, transaction mechanisms, and global standards. When embraced by digital platforms, these specifications empower the establishment of decentralized networks. In simpler terms, think of Beckn as a universally accepted set of communication rules agreed upon by multiple platforms. These rules enable users to seamlessly engage in discovery, ordering, fulfilment, and post-fulfilment activities in a standardised manner.
To draw an analogy, consider the broader internet itself. It operates on a foundation of protocols and specifications such as HTTP (Hypertext Transfer Protocol) or SMTP (Simple Mail Transfer Protocol) for emails. In a similar vein, Beckn provides a standardised framework for digital platforms to interact and transact.
It’s crucial to clarify that Beckn, including its current implementation, ONDC, is not an application designed to replace existing e-commerce systems. Rather, these are open specifications and standards aimed at fostering interoperability. To illustrate, think of the Unified Payment Interface (UPI), which serves as the underlying interface for interoperability among various stakeholders. UPI did not replace the banks; it simply enabled them to work more seamlessly with third-party payment apps and innovate continuously.
Similarly, ONDC aspires to be the underlying network that specialized players and e-commerce giants can integrate into their operations, leveraging the standardised protocols to enhance the e-commerce ecosystem without replacing it.
Let’s dive into the mechanics of the Beckn protocol by exploring its application in the context of a food delivery service like Swiggy or Zomato. The current food delivery ecosystem involves multiple stakeholders, each playing a vital role:
- The Restaurant (Service Provider): Restaurants utilise platforms like Swiggy or Zomato to showcase their menus, prices, operating hours, delivery areas, and more.
- The Consumer (End User): Customers place orders, provide delivery addresses, and explore available options in their vicinity through the Swiggy or Zomato customer app.
- The Delivery Rider: Responsible for collecting orders from the restaurant and delivering them to the customer. These riders rely on apps specifically designed for this purpose.
- Swiggy / Zomato (Platform): These platforms serve as the hub for discovering service providers and managing the entire ordering experience, including transactions. They are also responsible for recruiting riders in various areas to ensure efficient service.
This centralised approach places a significant burden and power to exploit on the platform, as it serves as the primary point of contact for discovery and transaction management. Every restaurant must register with each platform, and dedicated apps are required for delivery riders, making it platform-specific. This is a similar state in which digital transaction where a few years back with every player like Paytm / Google Pay having their own set of wallets with which transaction could happen within their apps and not across the apps.
Food Delivery reimagined using Beckn
Beckn simplifies every transaction to have fixed set of entities.
Service Provider: Service providers register with a Registry, a central authority responsible for listing various service providers. In the scenario, the restaurants are service providers who register themselves in the registry. The service providers interface to the network happens via a platform called as Beckon Providers Platforms (BPP). Once registered, service providers can BPPs to respond to various service requests. There is no locking into any specific BPP any provider can use any of the compliant BPP apps to be a part of the network.
Registry: Registries are maintained at local, national, and root levels ensuring location specific discoverability. Unlike the current scenario, these Centralised registries are not owned by specific platforms like Swiggy or Zomato but are administered by a central authority or institute. Think of them as similar to DNS registries that manage domain names.
Consumer: End users use applications developed by anyone like Swiggy or Zomato, to express their intent to consume a service which in this case is ordering food. These applications are known as Beckon Application Platforms (BAPs). These applications also don’t have any lock ins and an end user can make use of any of the compliant apps to consume services of these ecosystem.
Beckon Gateways (BG): When a user creates an intent using a BAP, Beckon Gateways step in. They are responsible for identifying relevant BPPs using the registry and broadcasts these intents to the providers. Once the BPPs receive the intent, these BPPs then individually respond directly to the BAP regarding the services they offer. The BAP can then filter and present the information to the user as per their interface. These gateways are independent networks which communicate to the BAPs and BPPs using the specifications. The responsibility of the gateways is limited to provide a high throughput network without worrying about the presentation layer.
Once a user selects a specific BPP, a direct connection is established between the BAP and BPP to facilitate the rest of the transaction. Because all applications adhere to the same set of specifications and use a central registry, a restaurant registered once is accessible on all platforms.
A similar process is followed for the delivery aspect as well. We can have a dedicated Gateway for logistics. The same BAPs which was used for the retails aspect can request services such as pickup dedicated gateway. In this case the riders becomes the Service provider with their own BPPs and can respond to the discovery request and provide the service, ensuring a seamless and interoperable experience for both service providers and end users.
Now that we understand what it is, and how can it be used, let’s try to understand what are the different specifications ?
As a protocol, Beckn is multi-layered, with layer structure and organization resembling that of HTTP. The architecture of the Beckn ecosystem has five layers (from top to bottom)
For the ease of understanding, one can draw a parallel of these layer with the familiar HTTP protocol layers
The bottom two layers — the Specification and Support layer and the Certification layer — provide all the resources and support required to implement the network, to test for compliance and to become certified to join the network.
The top two layers are the actual run-time of the specification in the form of the Application layer which constitutes the consumer and the provider interfaces, and the Network and Transaction layer which has the server-side applications and the routing infrastructure.
In the very middle is the Infrastructure and Security layer. This layer holds the underlying infrastructure that transforms the Beckn-compliant platforms into actual live transacting entities on an open network. The layer comprises of open registries which list the various platforms and makes them this discoverable by other platforms — a role similar to that of the domain name system (DNS) in HTTP.
Each of these layers has undergone unique independent evolution in terms of complexity and scale. Together, they all work in concert to create the ecosystem of Beckn. You can read more about each of the layers in details here
ONDC at this point in its initial onboarding phase, looking for people to be a part of the network and for platforms to build BPPs / BAPs or become a BG. The signs look positive with major players like Amazon showing interest to leverage the ONDC network. OLA has already launched their own food app on top of ONDC network, which I live now for everyone to use.
A relatively more adopted implementation of beckn is seen in the project of Kochi Open Mobility Network (KOMN). Which now has a network of over 5,000 drivers, the app completed 1,80,000 trips and enabled drivers to earn over ₹4.5 crore, without having to pay commission. There are plans to integrate even the public transport like buses to the same network as well.
