Choose a settlement flow
Billing calculates what charging costs. Payment settlement collects or returns money. Choose the owner of settlement before building checkout.
| Flow | Who integrates the processor? | Who calculates the cost? | Current availability |
|---|---|---|---|
| Ivora-managed payments | Ivora's registered adapter | Ivora tenant bill | Simulator; live Stripe on the tenant's reviewed payment account where Ivora has enabled it |
| Application-managed payments | Your backend, using any processor | Ivora immutable tenant bill | External sessions and optional reports available in production |
| Existing driver checkout | Existing Stripe checkout/settlement service behind an API adapter | Existing catalog and settlement engine | Not offered in production |
| Free or included charging | No processor for the session | Application policy; optional usage accounting | Application policy with generic commands or zero-cost external sessions |
| Simulation | Simulator | Simulated bill or workspace session | Available; no physical dispatch |
Diagram source
flowchart TD
Start[Choose a charging experience] --> Test{Only testing?}
Test -->|Yes| Sim[Simulation]
Test -->|No| Existing{Preserve existing driver checkout?}
Existing -->|Yes| Legacy[Existing driver settlement]
Existing -->|No| Money{Collect money per session?}
Money -->|No| Free[Free or included charging]
Money -->|Yes| Owner{Who owns processor integration?}
Owner -->|Ivora| Managed[Registered managed adapter]
Owner -->|Your application| External[External charging sessions]The external branch uses /v1/tenants/{tenant_id}/charging-sessions; your backend
owns the processor integration. Managed /payment/{service} routes still require
a registered adapter. Read the external workflow.
Responsibilities across all models
Your backend controls who may use a charger and when. Ivora enforces tenant and scope access; CSMS reports physical state and metering. A browser redirect is not proof of authorization, and a successful start command is not proof that energy was delivered.
Use one settlement owner for each charging transaction. Never attach a legacy-settled transaction to a new bill or create another payment to work around an uncertain result. Marketplace payouts, subscriptions and host revenue sharing are application features beyond the initial adapter.
Availability vocabulary
- Available: implemented and enabled in the production API; still subject to the documented limits and acceptance coverage.
- Proposed: design direction; no endpoint or request field is promised.
- Compatibility: preserves an existing service/ledger while clients migrate.
Processor-specific examples do not imply Ivora supports that processor today. The payment integration guide explains both integration ownership choices.