Beckn for EV charging: the complete guide

What Beckn changes

The default shape of a digital market is a platform in the middle. Buyers join it, sellers join it, and the platform owns discovery, transactions and the relationship with both sides.

Beckn removes the middle. It specifies a protocol that buyer-side and provider-side software use to transact directly, so any compliant app can discover and buy from any compliant provider without either having integrated with the other beforehand. Discovery is federated rather than centralised.

For EV charging in India this matters because the alternative is what already happened: a driver carrying five apps because five networks each built their own walled garden. On an open network one app reaches every operator, and operators compete on service rather than on app installs.

The actors

The specification uses standard requirement language throughout — MUST, MUST NOT, SHOULD and MAY — and the distinction is worth respecting when assessing whether an implementation is conformant or merely functional.

The transaction lifecycle

Every action has an on_ twin. The BAP sends; the BPP acknowledges immediately and calls back later. Each of these has a full guide.

The four phases

1. Discovery. The BAP searches; catalogues stream back from multiple BPPs over several seconds.
2. Selection and booking. select, init and confirm turn a listing into an order with an authorization token.
3. Charging session. The driver presents the token, the session starts, and status and update track it.
4. Completion. The BPP issues the final settled quote; billing follows from it.

Cross-cutting concepts

Everything is asynchronous

This is the single structural fact that shapes every Beckn implementation. There are no synchronous responses carrying business data. A request receives 200 ACK — meaning accepted for processing — and the answer arrives later as a separate HTTP request in the opposite direction.

BAP                                  BPP
 │                                    │
 ├──── POST /select ─────────────────►│
 │◄─── 200 { "ack": "ACK" } ──────────┤     receipt, not an answer
 │                                    │
 │                        (BPP works) │
 │                                    │
 │◄─── POST /on_select ───────────────┤     the actual answer
 ├──── 200 { "ack": "ACK" } ─────────►│
 │                                    │

Three consequences worth designing for from the start:

• Both parties run a server. A BAP is not just a client; it must receive callbacks at a publicly reachable, signature-verifying endpoint.
• State lives on your side. There is no request-scoped context to hold a transaction in. Every open transaction is persisted state with a TTL.
• Callbacks can be late, lost or duplicated. Idempotency and expiry are baseline requirements, not refinements.

Beckn and OCPI together

These are complementary layers, not alternatives, and the confusion between them is common enough to be worth stating plainly.

A realistic Indian deployment runs both. A CPO exposes a Beckn BPP so any buyer app can find and book its chargers, and simultaneously maintains OCPI connections with the eMSPs it has commercial agreements with. Underneath both, OCPP talks to the hardware.

The mapping is direct where it needs to be: a Beckn confirm produces an authorization token; when the driver uses it the CPO starts a session, and that session yields a CDR. Keeping transaction_id joined to the session and CDR is what makes Beckn orders and charging records reconcile — and skipping that join is why they often do not.

An implementation roadmap

Phases 1 to 3 are a working booking flow. Phase 4 is what makes it feel like a real product. Do not defer phase 1 — retrofitting signature verification onto a live endpoint means running an unverified endpoint in the meantime.

Production lessons

• Verify every inbound message. No staging bypass, no exceptions.
• One transaction_id per business transaction; a new message_id per request. The most common source of hard-to-reproduce bugs.
• Never treat ACK as success. Wait for the callback before telling a driver anything.
• Make confirm idempotent. Duplicate orders are the expensive failure mode.
• Handle unsolicited callbacks. Natural completion, faults and expiries all arrive without you asking.
• Render search results progressively and close the window at a few seconds. You never know how many providers will answer.
• Join transaction_id to the charging session and CDR, or reconciliation becomes guesswork.
• Serve catalogues from cache as a BPP. Broadcast search volume is not under your control.

Official references

The normative sources are the Beckn Protocol core specification and the domain specification for EV charging, alongside the UBC Technical Specification Document, which formalises EV charging semantics while keeping alignment with OCPI for CPO communication. A UBC EV sandbox is available for testing implementations against the network before onboarding.

The intended audience for that material is broad: consumer application developers building BAPs, eMSPs and aggregators mapping services across multiple CPOs, charge point operators exposing services as BPPs, and architects designing interoperable EV ecosystems.