> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Pre-authorisation and capture

> How Spirii authorises and captures payment for EV charging sessions, where the final cost is unknown at the start.

EV charging is an open-ended transaction: when a driver plugs in, neither they nor the platform knows exactly how long they'll charge or how much energy they'll use. Spirii uses a pre-authorisation and capture model to handle this — placing a hold on the driver's payment method at the start, then charging the exact amount at the end.

## How it works

### Pre-authorisation (hold)

When a driver starts a session via the app or a Spirii POS terminal, Spirii immediately pre-authorises the driver's card for an estimated amount. This places a temporary hold — the money is reserved but not charged yet.

The pre-auth amount calculated dynamically per charging session, calibrated to cover a typical session at that charger type and tariff. A higher-power DC fast charger at a motorway stop would have a higher pre-auth than an AC charger at a residential site.

### Capture

When the session ends, Spirii captures the exact amount based on the energy consumed and the tariff. The hold is released and replaced by the final charge. If the final amount is less than the pre-auth, the difference is released immediately; no separate refund is needed.

```
Session starts → pre-auth hold placed → session runs → session ends → exact amount captured → hold released
```

## Why this approach

Without pre-authorisation, the alternatives would be either:

* **Charge upfront for a fixed amount** — drivers feel overcharged if they stop early, or underpay and the session is cut off
* **Charge after the fact** — card authorisation can fail after the driver has already received the energy

Pre-auth avoids both problems: the driver is only charged for what they actually used, and the payment is confirmed before the session starts.

## Incremental authorisation

In the event that the charging session ends up being more expensive than the reservation, Spirii performs incremental authorisation to update the reservation instead of creating a new.

## Payment method reuse

In the event that charging fails to start, Spirii will reuse the reserved funds if another charging session is attempted with the same payment method. This ensures that customers can retry on chargers with poor connectivity or with other issues.

## Failed pre-authorisations

If a pre-authorisation fails (insufficient funds, card declined), the session does not start. The driver sees an error in the app and is prompted to use a different payment method.

## Failed captures

If a capture fails after a session has completed (for example, a card expires between the start and end of a long session), Spirii retries the charge automatically. If retries are exhausted, the session is marked as unpaid in Spirii Connect.

## Terminal sessions

For payment terminal sessions, the pre-authorisation is handled by the PSP (Worldline, Elavon, Stripe, or another PSP depending on the setup). The terminal displays the pre-auth amount to the driver before they confirm with a tap or PIN. The capture follows the same logic as app sessions — the exact amount is captured when the session ends, based on the OCPP stop signal from the charger.

Terminal sessions managed by Spirii's POS integration also reuse reservations to minimise the impact of charger malfunctions on the customers' bank accounts.

## Related

<CardGroup cols={3}>
  <Card title="In-app payments" icon="smartphone" href="/capabilities/payments/in-app-payments">
    How app-based payment sessions work from driver to payout.
  </Card>

  <Card title="In-person payments" icon="credit-card" href="/capabilities/payments/in-person-payments">
    How terminal sessions handle pre-auth and capture.
  </Card>

  <Card title="Sessions and CDRs" icon="receipt" href="/components/charging/sessions-and-cdrs">
    The session and CDR data that drives billing and payment status.
  </Card>
</CardGroup>
