Payments and billing

Add and manage payment methods

Payment methods in the profile lists everything saved to the account. Add payment method stores a new card or another supported method, and Set as primary payment marks one of them as the default: the primary method is where the hold is placed automatically when a session starts, without the driver picking anything at the charger. For an individual transaction the app can still ask "Select the payment method for this transaction:", so the primary choice is a default, not a lock-in.

[IMAGE: Payment methods screen listing saved cards, with Add payment method and Set as primary payment]

Two rules protect payments already in flight:

• A method being used by an active charging session cannot be deleted until that session completes. The app shows "Payment method in use" if deletion is attempted mid-session.
• A method linked to upcoming bookings can be deleted, but doing so cancels those bookings, and booking fees already paid are not refunded. The app warns before the deletion goes through.

Important
Deleting a card that upcoming bookings depend on cancels all of those bookings at once. Moving the bookings' payment to another method first, or waiting until after the booked sessions, avoids losing paid booking fees.

Not every deployment saves payment methods at all. In some, every card payment is a one-time transaction entered at checkout, or sessions are paid entirely from the Wallet balance instead. In such a deployment, the absence of a saved-cards screen is the intended payment model, not a missing feature.

Availability: the payment model itself varies per deployment; saved cards, one-time checkout, or Wallet-only payment can be used depending on the business case of the individual operator.

The pre-authorization hold

Charging costs cannot be known in advance, since nobody knows how much energy the car will take until it is unplugged. To guarantee the session can be paid without charging blindly, the app places a Pre-authorization when a session starts: a temporary hold that reserves an estimated amount on the payment method. The app states the exact amount up front with the message "We will authorize [amount]. Any unused amount will be returned."

The full lifecycle:

1. At session start, the hold reserves the estimated amount. No money leaves the account; the bank only sets it aside.
2. When the session ends, the actual session cost is captured from the hold.
3. The remainder is released on the app's side immediately when the session ends. The bank then takes its own time to clear the reserved amount from the account, typically 1 to 7 business days.

[IMAGE: Pre-session confirmation showing the authorization amount message]

Important
A session that appears failed while money still shows as reserved on the card is almost always the pre-authorization hold, not a captured payment. Nothing was taken; the reservation disappears on its own once the bank processes the release, typically within 1 to 7 business days.

The Wallet

The Wallet is a prepaid balance held inside the app. Drivers top it up with any available payment method or by redeeming a voucher code, and the balance then pays for charging sessions and bookings directly. Because the money is already reserved in the balance, sessions paid from the Wallet skip the per-session card check entirely, which also removes the possibility of a card declining mid-charge.

Two constraints shape how the balance behaves:

• A Wallet balance cannot be withdrawn. Once credit is added, it can only be spent on charging and bookings inside the app.
• If a balance goes negative, for example because a session cost more than the remaining credit, the next top-up first settles that outstanding amount. Only what is left over after settlement becomes new usable credit.

[IMAGE: Wallet screen showing the current balance, transactions, and a top up option]

Availability: optional per deployment; the Wallet can be used depending on the business case of the individual operator.

Retrying a failed payment

When a session's payment cannot be completed, for example because the card was declined, the unpaid session cost stays on the account as an outstanding balance. The app blocks new charging sessions until that balance is cleared, showing "Payment issue detected" with the explanation "We could not process the payment for your last charging session. Please clear your balance before starting a new session."

Retry payment resolves it:

1. The prompt shows the amount due from the failed session.
2. The driver picks an existing payment method or adds a new one, which is the usual fix when the original card was the problem.
3. Retry payment charges the amount and unblocks charging.

[IMAGE: Retry payment prompt showing the outstanding balance and payment method choice]

Billing and cost breakdown

What a session is actually billed for, energy, time, idle fees, booking and session fees, tax, and how receipts work, is covered line by line in Billing and cost breakdown.

Common questions

What if a reserved amount is still visible more than a week after the session? The app releases its side of the hold the moment a session ends, so anything visible after that point is the bank's own clearing process. Past the typical 1 to 7 business day window, the driver's bank is the party that can explain the delay, since no further release action remains on the app's side.

Why does the hold amount differ from the final session cost? The hold is sized on an estimate made before any energy has flowed. The final cost is calculated from what the session actually consumed, so it is normally lower than the hold, and only that final amount is ever captured.

Can a driver in a deployment without saved cards still avoid typing card details every session? Where the Wallet is available, yes: topping up once and paying sessions from the balance replaces per-session checkout entirely.