English (UK) 
English (United States) 
Chinese 
Arabic 
German 
Spanish 
Korean 
Japanese 
Italian 
French (France) 
Vietnamese 
Malay 
Indonesian 
French (Canada) 
Dutch 
Swedish 
Thai A driver finishes a short charging session and sees a much larger amount pending in their banking app. They contact support, convinced they have been overcharged. Meanwhile, the operator sees the correct session total and assumes there is nothing to investigate.
Both screens can be showing valid information. The larger amount may be an authorization hold, while the smaller amount is the final charging fee. A well-designed payment journey makes that distinction clear and gives support staff enough information to explain it.
Quick answer: EV charging preauthorization reserves an amount on an eligible payment method before the final fee is known. Capture collects the final payable amount within the provider’s permitted rules. Canceling an unused authorization releases a hold; refunding returns money that has already been collected. These actions have different states and should not share one generic “refund” label.
1. Why EV charging sometimes uses a payment hold
At the start of a charging session, the operator may not know the final energy delivery or duration. Preauthorization is one way to check that funds are available before providing a service with a variable total. It is not the only model: wallets, prepaid balances and account billing follow different workflows.
The authorization amount should reflect a documented commercial policy. An unnecessarily high hold can frustrate drivers, while an amount too low for the intended session may create collection risk. The right approach depends on your audience, payment provider, average session and supported capture options.
For the basic distinction, see Stripe’s documentation on separate authorization and capture. That documentation describes eligible methods and authorization expiry. It does not mean that every gateway or local payment method uses the same rules.
2. Keep authorization, capture, cancellation and refund separate
| Action | What it means | What the driver may see |
|---|---|---|
| Authorize | Reserve an approved amount before collection | A pending amount or reduced available balance |
| Capture | Collect the agreed payable amount | A completed charge, sometimes alongside a pending hold temporarily |
| Cancel authorization | Stop an uncaptured payment and release the hold | The pending amount disappearing when the issuer updates it |
| Refund | Return all or part of a captured payment | A credit or reversal after processing |
| Reconcile | Match session and payment records | Usually an internal process, with a corrected receipt if needed |
These terms matter because the next action depends on the current state. A session that never started may need an authorization cancellation. A completed and captured session with an incorrect fee may need a partial refund. Calling both situations “refunded” leaves drivers wondering why their bank statement looks different.
Payment status should also remain separate from charging status. “Charging completed” does not prove that collection succeeded, and “payment authorized” does not prove that electricity was delivered. Your records need to link both processes without treating them as the same event.
3. Design the normal session flow
Before payment, show the tariff, any additional fees and the proposed hold in clear language. Explain that the authorization is temporary and that the final charge depends on the session. Put this information where the driver makes the payment decision, not only in a long terms page.
After authorization, request the charging start and wait for the appropriate evidence from the charger. Save the session identifier and payment reference together. If the charger does not start within the agreed workflow, show a useful status and follow the defined cancellation or investigation process.
When the session ends, calculate the fee from the recorded data and applicable tariff. Submit the supported capture action, record its result and issue a receipt with the final amount. The receipt should identify the site, connector, time period, charging quantity and support route.
In a simplified example, an operator authorizes $30 and the verified session fee is $8.40. If the provider supports the agreed partial-capture workflow, the system collects $8.40 and handles the unused authorization according to provider rules. This is an illustrative transaction, not a recommended hold amount.
4. Define what happens when the journey breaks
Consider the case where authorization succeeds but the charger rejects the start request. The platform should not interpret payment approval as a completed charging service. It needs to connect the failed start with the related payment and follow the documented cancellation policy.
Another common case is an interrupted connection at the end of charging. The final meter value may arrive later than the payment workflow expects. Define how the system waits, retries or escalates without inventing a final amount. Where local data can be recovered, use that evidence through the agreed reconciliation process.
A session can also cost more than the initial authorization. Do not assume that the platform can simply capture any larger amount. Additional authorization, incremental authorization or a different collection method may be required, depending on provider support and the commercial setup. Decide that behavior before launching.
If authorization expires before capture, treat it as a specific exception with an owner. Supported validity windows vary, so the integration should use the provider’s payment state and expiry information rather than a universal hard-coded deadline.
5. Give refunds their own auditable workflow
A refund starts with an already collected payment. The operator needs a reason, an approved amount and a link to the original transaction. The system should record who requested it, who approved it where required and whether the provider accepted, completed or rejected the request.
Partial refunds are useful when only part of the fee needs correction. For example, the energy charge may be valid while an incorrectly applied idle fee needs to be returned. Preserve the original receipt and record the adjustment rather than silently rewriting the transaction history.
Stripe’s refund documentation distinguishes canceling incomplete payments from refunding successful ones and describes pending or failed outcomes. Build support procedures around the actual provider states. A submitted refund request should not automatically become a message promising that money has reached the driver.
Avoid promising a fixed release or refund time unless the provider and issuing-bank conditions support it. Explain what your system has done and give the customer a payment reference for follow-up.
6. Make the integration resilient to repeated or delayed events
Payment notifications are part of the operational design, not background plumbing. A driver can close the browser, a mobile connection can drop, and the payment provider may deliver an event after the visible charging screen has stopped updating. The backend still needs to reach the correct financial state.
Use verified provider notifications and check the current payment object when necessary. Record event identifiers, protect actions against duplicate processing and account for events arriving out of sequence. A repeated notification should not create a second capture or refund.
Stripe’s webhook documentation explains asynchronous event handling, signature verification and delivery considerations. Your implementation should follow the selected provider’s requirements. Operationally, staff also need a queue of unresolved cases rather than a green dashboard that hides missing notifications.
The existing EV charging API integration guide provides wider context for connecting the platform with payment and business systems. Define the payment state model explicitly in the project scope.
7. Reconcile the session, payment and settlement records
A useful daily review connects three views: what the charger delivered, what the driver was charged and what the provider reports for settlement. Match records using stable identifiers, not only an amount and an approximate time. Two different drivers can easily have sessions with identical prices.
Flag sessions without a completed payment, payments without a corresponding session, duplicate captures and refunds awaiting resolution. Assign each exception to the team that can investigate it. Finance should also understand how provider fees and settlement adjustments appear.
Direct card payments and roaming settlement are different relationships. If the driver charged through an external mobility provider, the commercial reconciliation may depend on partner records and invoices. For that workflow, read the guide to roaming reconciliation from CDRs to settlement rather than applying a direct-card procedure unchanged.
8. Test the uncomfortable cases before launch
Run controlled tests for declined authorization, successful authorization followed by a failed start, a normal partial capture, duplicate callbacks, a delayed final session record and an expired authorization. Add full and partial refunds, including a refund that remains pending or fails.
For every case, check four things: the driver message, charging-session state, provider payment state and finance record. All four should tell a consistent story. A technically successful API request can still produce a confusing customer experience if the wording describes the wrong event.
Have support staff rehearse the explanation for a pending hold. They should be able to find the authorization, final charge and relevant reference without requesting unnecessary banking information from the customer.
Frequently asked questions
Is an EV charging payment hold an extra fee?
A hold reserves funds; it is not necessarily an additional completed charge. Drivers should check whether the amount is pending or settled. Operators should provide the final receipt and investigate any mismatch between the captured amount and the verified session fee.
Can every payment method use preauthorization?
No. Support depends on the method, provider, merchant setup and region. Some payment journeys need a prepaid, immediate-payment or account-billing model instead. Confirm the actual integration before advertising a particular payment experience.
Why can a refund be pending?
The outcome depends on the provider and transaction state, and completion may involve the issuing bank. A support team should distinguish a refund request from a completed refund and use the provider reference when investigating.
Specify the payment behavior you need
TRENDPOWER’s charging payment solution covers the broader relationship between tariffs, payment integrations and financial operations. When you discuss your payment project with TRENDPOWER, specify the target market, merchant arrangement, selected provider and required exception workflows. Confirm preauthorization, capture and refund support as explicit integration requirements rather than assuming that a payment logo proves the complete journey.
