Transaction Layer

Topic Summary (TL;DR)

The Transaction layer consists of Beckn Application Platforms (BAPs), on one side, Beckn Provider Platforms (BPPs), on the other, and Beckn Gateways (BGs), in-between them. BAPs acquire consumers, and place orders, BPPs acquire orders and fulfill them, and BGs optimize discovery of BPPs (by the BAPs) on the network, and can also provide additional functional and value-added services to a network. Additionally a fourth entity called the Network Registry or simply Registry provides an additional layer of trust on the network by listing platforms that are compliant to a network’s rules and policies.

A beckn-enabled network can form different ad-hock virtual topologies based on the needs of the use case at hand.

Overview

The Transaction layer of a Beckn-enabled network is the abstraction that encompasses the network actors and the transactions that occur between them. The Transaction layer itself has three distinct parts:

• Demand side — the consumer-facing platforms called “Beckn Application Platforms” or, for short, “BAPs”
• Supply side — the Seller-facing platforms called “Beckn Provider Platforms” or, “BPPs”
• Routing infrastructure — the entities between the supply and demand sides, called of “Beckn Gateways” or “BGs”, which connect the BAPs and the BPPS

Let’s now expound on the roles of each of these parts and see how transactions take place in this layer.

Network Actors

Beckn Application Platforms (BAPs)

A Beckn Application Platform (BAP) is a consumer-facing infrastructure which captures consumers’ requests via its UI applications, converts them into beckn-compliant schemas and APIs at the server side, and fires them at the network. BAPs are the initiators of transactions and have the flexibility to communicate with multiple networks and integrate the responses from these networks into a bundled transaction experience. For example, a BAP can book a cab via an urban mobility network, order a coffee from a restaurant via a local-retail network, have it picked up via an order on a delivery network and get it delivered on the way to work. All these three services can be bundled on the BAP’s server end and packaged into a single, rich, integrated experience. Similarly a BAP can bundle multiple modes of transport to offer a multi-mode journey to the a app user. For example, a BAP application can provide a cab + metropolitan + bus ride, all in the same booking.

BAPs are software applications that provide consumer services to the end-user. They take advantage of beckn’s open network infrastructure to offer integrated experiences that, seamlessly to the consumer, aggregate services from different sources which can reside on different networks. The term “BAP” refers to any shopping software platform or software package on a beckn-enabled network which has a beckn protocol compliant API. Some examples of BAPs could be:

• Shopping apps
• Shopping websites
• Consumer Voice assistants

A BAP has:

• A server-side beckn protocol API
• Consumer-centric UI/UX

A BAP can be set up by any organization which intends to offer integrated services to consumers but does not want to maintain an active inventory of products and services.

Beckn Provider Platforms (BPPs)

The other side of the network is the supply side which consists of Beckn Provider Platforms (BPPs). These are the platforms that maintain an active inventory, one or more catalogs of products and services, implement the supply logic and enable fulfillment of orders. The BPP can be a single provider with a Beckn API implementation or an aggregator of merchants — this, of course, depends upon the logic of the particular implementation.

A Beckn Provider (BP) — a business or non-profit entity that supplies services via BPP — can be any organization that owns, operates or manages an inventory of one or more services. BPs may be required to register with the national or local authorities and be regulated by them. Some examples of BPs are,

• Public transportation companies like metropolitan services, bus services, ride-hailing services, etc.
• Restaurants
• Final-mile delivery services for food and groceries

A BPP has:

• An API to accept requests from BGs or BAPs as part of the application cloud (Beckn Provider API)
• Service personnel UI. This is optional and may not be required for all cases. For example, a bike rental might not require a user interface, whereas a cab service may require a driver app.
• An application cloud to store inventory data

Beckn Gateways (BGs)

Between BAPs and BPPs are the Beckn Gateways, which form the routing infrastructure of the Transaction layer. BGs are extremely lean and stateless routing servers. The purpose of this infrastructure is to optimize discovery of BPPs by the BAPs by merely matching the context of the search. The BG takes a request from the BAP, determines to which BPPs the message needs to be sent to (by looking up the registry) and multicasts the message only to them. Apart from that, it can also implement optional features like payment gateways, registry services, online dispute resolution services, and can sometimes also emit Open Data (OData) provided the network policy allows it.

The purpose of a BG is to also allow all BPPs on the beckn-enabled network to have a fair chance to be discovered by any BAP. The BG broadcasts the search request to all listed and active BPPs on the network registry, which ensures fair and equal access to any participant. Furthermore, there is a post-discovery lifecycle that occurs directly between the BAP and BPP after the BAP has chosen the BPP to fulfill the BAP’s Intent (the BAP’s search).

A BG has:

• A cloud infrastructure with services to implement the above functionalities. The implementation is done over the Beckn protocol specifications.
• An API to accept requests from BAPs (Beckn Gateway API).

BGs validate and filter all requests based on the national and local governance policies. They can also optionally collect payments from the BAPs’ users, and implement Online Dispute Resolution systems (ODRs) to settle disputes among BAPs and BPPs.

Any organization with infrastructure to provide the above functionalities (preferably organizations that own infrastructure with high throughput capacities) can be a BG. Such organizations may be regulated entities registered with the national and/or local authorities.

API Communication

All Transaction APIs communicate between the BAP and the BPP, with the exception of the Discovery API. All request messages are non-blocking and are immediately acknowledged with an ACK or a NACK message in the same session. The response message is in the form of a callback. Each callback, too, is immediately responded to with an ACK or a NACK message in the same callback session. All messages are serialized in JSON.

Exceptions

Beckn protocol does not support is order tracking in real time. Real-time tracking data is not routed through the beckn-enabled networks. Because tracking involves continuous streams of data through an open socket. The same exception applies to any real-time communication between the BPP and the BAP, like chat or cloud calling. For example, in the case of vehicle tracking, only the tracking URL is transmitted, and not the tracking data itself.

Network Topologies

Beckn-enabled networks form various configurations depending on the nature of the integration of the use cases involved. For example, when a consumer wants food delivered to their home, there are two networks which are accessed:

• Local Retail network — for placing the order for the food
• Final-Mile Delivery network — for picking up the food package from the restaurant/store and delivering it to the consumer

One way to fulfill this use case is for the customer-facing BAP to use the Local Retail network to order food, while accessing the final mile delivery network in parallel and placing a delivery request there:

Alternatively, the Local Retail BPP may act as a BAP and place the delivery request to the Final Mile Delivery network in a cascaded manner like this: