Skip to main content
Spirii reserves an estimated amount on the driver’s payment method when a session starts, then charges the real one when it ends. Nobody knows the price at plug-in, which is why payment happens in two steps.

​
Overview

Every session on the platform is paid for this way, whether the driver started it in an app or tapped a card at a terminal. The reservation goes on at the start and the charge at the end, with the difference released rather than refunded. Doing it in that order means a card that is going to decline declines before any energy reaches the car. It also means a driver’s statement shows a reservation for one amount and a charge for another.

​
How it works

Two of these steps run on every session. The other two cover a session that costs more than expected, and one that never starts.
When a driver starts a session in Spirii Go or a branded app, Spirii pre-authorises their card for an estimated amount. The money is reserved, not charged.The amount is calculated per session from the location’s tariff. Locations that are neither public nor roaming-enabled use a lower multiplier, so a workplace site reserves less than a public one on the same tariff.On a payment terminal, the PSP places the reservation instead. See Terminal sessions.
When the session ends, Spirii captures the exact amount from the energy consumed and the tariff. The reservation is released and replaced by the final charge.Where the final amount is lower than the reservation, the difference is released immediately. No separate refund is needed.
If a session runs past what the reservation covers, Spirii raises the existing one by incremental authorisation rather than opening a second.One reservation, one charge — however long the session turns out to be.
Spirii keeps the reserved funds when charging fails to start, and reuses them if another session is attempted on the same payment method. A driver who meets a charger with poor connectivity can move to the next one.Without this, every failed attempt would leave its own reservation sitting on the card.

​
When a payment fails

Where the failure lands decides what happens next, and the dividing line is whether the energy has been delivered yet.
The session does not start. Insufficient funds or a declined card means no reservation, and no reservation means no charging.The driver sees an error and is prompted for a different payment method.
The energy has already been delivered, so Spirii retries the charge automatically, a few times over the following days. A card expiring between the start and end of a long session is the common cause.If the retries are exhausted, the session is marked as unpaid in Spirii Connect.

​
Terminal sessions

On payment terminal sessions the reservation is placed by the payment service provider (PSP) rather than by Spirii: Worldline, Elavon, Stripe, or another, depending on the setup. The terminal shows the driver the pre-authorisation amount before they confirm with a tap or a PIN. Capture follows the same logic as an app session. The exact amount is taken when the session ends, triggered by the OCPP stop signal from the charger. Terminals running Spirii’s POS integration also reuse reservations, so a charger malfunction does not leave a driver with several reservations against their bank account.

​
Dependencies & limitations

  • The reservation is an estimate, and the driver sees it. It is sized from the location’s tariff, so it rarely matches the final price. A driver checking their banking app mid-session sees the reservation, not what they will pay.
  • A session running longer than seven days is not paid out. Revenue cannot be guaranteed on a reservation held that long, so those sessions are excluded from your self-billing invoice. See Understanding your payout.
  • On terminal sessions, the PSP owns the reservation. Spirii captures against it, but the pre-authorisation itself follows that provider’s rules rather than Spirii’s.
  • Reservation reuse covers app and Spirii POS sessions. A terminal running a charger manufacturer’s POS or a third-party POS handles its own reservations, so the behaviour there is that provider’s.

In-app payments

How app-based payment sessions work from driver to payout.

In-person payments

How terminal sessions handle pre-auth and capture.

Sessions and CDRs

The session and CDR data that drives billing and payment status.