Ownership and application architecture

Keep application features outside the charger protocol engine. Build host/guest ownership, booking windows, subscriptions and user-facing permissions in your application backend, then call Ivora with a scoped tenant credential.

The API cutover covers charger management and billing support. Ivora's applications use these shared capabilities while retaining their own product workflows. New application features should normally need only app code.

Diagram source

flowchart TB
  Guest[Guest or host UI] --> App[Application backend]
  Agent[Application AI assistant] --> App
  App --> Rules[Booking and user authorization]
  Rules --> API[Ivora unified API]
  API --> Billing[Tariff snapshots and bills]
  API --> Charging[CSMS adapter]
  Charging --> Core[OCPP engine]
  Core --> Charger[Physical charger]
  Billing --> Adapter[Optional managed payment adapter]
  Adapter --> Processor[Payment processor]
  App --> External[Application-owned payment integration]

Ivora's own applications follow the same boundary. For example, Ivora Host creates its printable QR cards and driver links in the Host frontend, using station/EVSE identifiers read from the API. A different application can create different signage and links without changing the API or CSMS. A QR link does not grant charger access; the destination application still enforces authorization. Host also asks the API to show the same link on the charger's screen through charger displays. The API owns delivery to the screen; the link and its page remain application choices.

A charger-sharing application

A tenant credential can operate the fleet granted to that tenant. It does not grant access to other tenants. Your backend maps each charger to a host and each booking to a guest. It checks those records on every request, including reads, event streams and AI tool calls. Never expose a fleet key to guests.

One application's tenant may contain many hosts. Merchant account selection must be bound to trusted host/booking records; a client-selected merchant ID is not authority to route payment. The managed adapter charges one Stripe account per tenant, the one pinned in Ivora's payment provider. Per-host merchant accounts within a tenant, commissions and host payouts are separate features and are not implemented by the initial managed payment adapter.

Current migration boundary

Platform Host calls the unified API for charger resources and its own backend for profiles and eligibility. Driver pages call the Host application backend, which uses the unified API for charging/billing. Business profiles, password hashes and receipt branding live in the Host application's database. The API has no business-profile or free-charge policy endpoint. New Host complimentary sessions use generic external sessions and zero-cost tariff snapshots after application authorization. Ivora Host's charger registry, provisioning, pricing and paid checkout orchestration run in its own application on the tenant contract; the /v1/host account routes were retired on 2026-09-25. The production API serves none of the adapters that preproduction keeps for existing Ivora experiences: no driver or legacy checkout routes. Stripe Connect account setup is the tenant payment account contract; paid Host sessions are direct charges on that account once Ivora has enabled live payments and approved it.

Compare settlement models before choosing endpoints. Adding a processor should change payment/application code, without changes in the OCPP engine. Self-service registration of externally hosted adapters remains proposed.