ProductionOpal BPM India Pvt Ltd

Beckn Protocol Verification Adapter

An RFC 1.2.0-compliant Beckn adapter ("WRI Connector") for identity verification across multiple providers, with sub-50ms P95 latency.

Type: Enterprise case study
Client / company: Opal BPM India Pvt Ltd
Stack: 5 technologies

Business Problem

Beckn is an open, decentralized transaction protocol used to make discovery, ordering, and fulfillment interoperable across independent networks (the same protocol family behind India's ONDC). Opal needed an adapter — internally referred to as the WRI Connector — that could sit between Opal's systems and multiple external identity-verification providers while staying compliant with the Beckn RFC 1.2.0 specification.

My Role

I built the WRI Connector: the protocol-compliance layer, the provider-integration model, and the multi-tenant isolation approach. This was an individually-owned build within the broader Opal platform work, not a shared team deliverable split across multiple engineers.

Technology Stack

Python 3.12+FastAPIPostgreSQLCeleryDocker

Architecture Summary

The adapter is a Python 3.12+ service built on FastAPI, with PostgreSQL for state and Celery for asynchronous task processing. It supports 5+ verification providers behind a common interface, uses an explicit state machine to validate each verification request's lifecycle, deduplicates by message ID to guard against retried/duplicate Beckn callbacks, and isolates tenants cryptographically using Ed25519 signatures rather than relying on data-layer isolation alone.

Technical Challenges

Building a strict, spec-compliant implementation of an evolving open protocol (Beckn RFC 1.2.0) while integrating 5+ real-world provider APIs that don't perfectly agree with each other on timing, retries, or error semantics.

Engineering Decisions

Model the verification lifecycle as an explicit state machine.

Why — Beckn interactions are asynchronous and multi-step (discovery → verification request → provider response → confirmation); an explicit state machine makes illegal transitions impossible and makes the adapter's behavior auditable against the RFC.

Use Ed25519 signatures for multi-tenant isolation rather than isolation by database schema/row alone.

Why — Beckn's own trust model is signature-based; aligning tenant isolation with the protocol's native cryptographic model avoids maintaining a parallel, adapter-specific isolation mechanism.

Deduplicate incoming requests by message ID.

Why — Beckn callbacks can be retried by the network; without deduplication, a retried callback could double-process a verification and corrupt state.