One platform. Any charging product.
How Stackbox built a dual-layer MSP platform that cleanly separates OCPI protocol logic from custom product interfaces – so new charging services launch in days, not months. We designed the architecture others thought was impossible.
01 · Challenge
Every product rebuilt OCPI from scratch.
MSPs launching new charging products – subscriptions, discounts, loyalty – faced the same hidden cost every time: rebuilding the entire OCPI integration layer from zero. This isn't fate. It's an architecture problem – and we have the solution.
Tight Coupling
Because OCPI logic lived inside the product code, even minor protocol updates required changes across every interface simultaneously. A single OCPI spec revision could block three teams.
Slow Time to Market
New product interfaces took months because engineers had to build and validate the full protocol stack before reaching actual product logic. The 80% infrastructure, 20% product split destroyed velocity.
MSP product development was conflating two fundamentally different problems: implementing a protocol standard (OCPI) and building product interfaces. Without a clean architectural boundary between these layers, every product paid the full infrastructure cost — and carried the full maintenance burden. We changed that.
02 · Solution
A shared OCPI core. Unlimited product interfaces.
Stackbox designed a dual-layer platform architecture that draws a hard boundary between the OCPI protocol core and all product-facing interfaces – letting each layer evolve independently. Built right once, it scales without added effort.
OCPI Core Layer
A single, hardened OCPI 2.2.1 implementation handles all protocol-level concerns: CDR ingestion and validation, token authorisation, session synchronisation, tariff management, and location feed distribution. No product code touches the protocol directly.
Internal Event Bus
The OCPI core emits structured events for every significant protocol action – session start, CDR received, token validated. Product interfaces subscribe to relevant events without polling or coupling to protocol internals.
Product Interface Layer
Custom products and partner APIs are built as independent interfaces that consume the internal API and event stream. Each interface owns only its product logic – nothing else.
Extension Pattern
New product interfaces follow a documented extension pattern: subscribe to events, call the internal API, expose a product-specific surface. A new interface from concept to production takes days, not months.
Dual-Layer Interface Architecture
Integration
03 · Impact
What changes for MSPs.
The dual-layer architecture eliminates duplicated infrastructure work, accelerates your product development, and makes the platform resilient to OCPI spec changes. Because we know how to build this right.
OCPI implementation shared across all products – built and maintained once
time to launch a new product interface, down from months
product interfaces broken by OCPI spec updates – the core absorbs all changes
products served from a single platform deployment
session events delivered to all subscribed interfaces within seconds
focus on individual charging products – so that you can stand out in the market
Before Stackbox, every new product we launched meant trying to use OCPI stack for other purposes. Now the protocol layer just exists — and our teams focus entirely on product. We shipped our subscriptions in three weeks. It would have taken six months before.
Stackbox · MSP App
Building an MSP product?
We'll walk you through the dual-layer architecture and show you exactly how your product fits – with your OCPI setup, your product interfaces, and your target markets.
Let's talk →