status: tracking an active order

Two states, and only one of them is interesting

An order carries a status, and each fulfilment carries its own state. They answer different questions.

The order status stays ACTIVE for the entire charge. It tells a driver nothing. Everything the UI needs — has charging started, is energy flowing, how much so far — lives in the fulfilment state and its associated tags. Building a progress screen on order status produces an interface that never changes.

The request and response

POST https://cpo.electreefi.in/beckn/status

{
  "context": {
    "domain": "ev-charging:uei", "action": "status", "version": "1.1.0",
    "bap_id": "emsp.example.com", "bap_uri": "https://emsp.example.com/beckn",
    "bpp_id": "cpo.electreefi.in", "bpp_uri": "https://cpo.electreefi.in/beckn",
    "transaction_id": "txn-4471", "message_id": "msg-9031",
    "timestamp": "2026-08-11T09:35:00Z"
  },
  "message": { "order_id": "ord-EFI-2026-0811-4471" }
}

The callback carries the live picture:

POST https://emsp.example.com/beckn/on_status

{
  "context": { "...": "same transaction_id", "action": "on_status",
               "message_id": "msg-9031" },
  "message": {
    "order": {
      "id": "ord-EFI-2026-0811-4471",
      "status": "ACTIVE",
      "fulfillments": [{
        "id": "FUL-1",
        "state": { "descriptor": { "code": "CHARGING" } },
        "tags": [{
          "descriptor": { "code": "progress" },
          "list": [
            { "descriptor": { "code": "energy_delivered" }, "value": "18.400" },
            { "descriptor": { "code": "power" },            "value": "48.2"   },
            { "descriptor": { "code": "started_at" },
              "value": "2026-08-11T09:12:00Z" }
          ]
        }]
      }],
      "quote": {
        "price": { "currency": "INR", "value": "401.67" },
        "breakup": [{ "title": "Energy (18.4 kWh @ 18.50)",
                      "price": { "currency": "INR", "value": "340.40" } }]
      },
      "payments": [{ "id": "PAY-1", "status": "NOT-PAID",
                     "type": "POST-FULFILLMENT" }]
    }
  }
}

Unsolicited on_status is the better pattern

Beckn permits a BPP to send on_status without a preceding status request. For EV charging this is not a nicety — it is the difference between a good driver experience and a bad one.

Push on the transitions that matter — charging started, charging stopped, fault raised, session complete — and optionally on a slow heartbeat during a long charge. A BAP still needs polling as a fallback, because pushes get lost, but it should be a safety net rather than the primary mechanism.

This is the same push-plus-reconcile pattern that OCPI uses for Locations and Sessions, and for the same reason: a lost push is silent.

The states that matter for EV charging

Two gaps worth designing around. First, a session can sit in CHARGING while the vehicle has stopped drawing power — a full battery does not change the state. Compare energy_delivered across successive updates to know whether anything is actually happening. Second, COMPLETED does not mean billed; the final amount follows once the CPO has finalised metering.

Production lessons

• Drive the UI from fulfilment state, never order status.
• Implement unsolicited push if you are a BPP. Polling scales badly on an open network and delivers a worse experience.
• Keep polling as a fallback if you are a BAP, but back it off once pushes are arriving reliably.
• Guard against out-of-order callbacks. Use the context timestamp and discard anything older than the state you hold — the same rule as OCPI's last_updated.
• Age out stalled orders. A charger that drops offline mid-session leaves an order stuck in CHARGING forever unless you time it out.
• Never bill from a status quote. It is an estimate until the transaction closes.