“I returned the power bank, but my banking app still shows the deposit.” This message needs a precise check before anyone promises a refund. The visible amount may be an uncaptured authorisation, a completed rental charge, or a payment that genuinely requires correction. Each situation has a different action and a different explanation.
In an agreed CoreCharge authorisation-based rental flow, the physical reader starts the payment process, the cabinet releases the unit after the required payment state, and the return event supports calculation of the final rent. Stripe handles the money in the operator’s own account. Support must compare the rental timeline with the payment record.
Start with the return evidence
Ask for the approximate rental time, venue, station identifier and available order reference. Retrieve the order and check release and return events, the relevant device and slot, rental duration and tariff version. A customer saying the unit was inserted is useful evidence, but the system record still needs examination if the order remains open.
Do not request a full card number, bank password or screenshot containing unrelated transactions. Use the minimum information needed to find the record, and keep support material access-controlled. If a payment lookup remains ambiguous, escalate it to the authorised operator rather than guessing from the amount alone.
Classify the payment before taking action
Stripe separates authorisation from capture for eligible methods. An uncaptured payment can be cancelled; a smaller final capture releases the unused authorised amount. A refund applies after a payment has succeeded. See the official guides to authorisation and capture and refunds and cancellations.
| Observed situation | Check | Appropriate support direction |
|---|---|---|
| Returned order; authorisation remains uncaptured | Final rent and required completion action | Complete the agreed capture or cancellation workflow |
| Correct final rent captured; original hold still visible | Captured amount and released remainder | Explain the hold and provide the payment reference |
| Captured rent exceeds the correct rental amount | Return evidence, tariff and authorisation to adjust | Issue the authorised partial or full refund |
| Refund requested but not complete | Refund status and any failure reason | Track the existing refund before issuing another |
| Return missing or payment status uncertain | Device events and authoritative Stripe result | Investigate before making a financial correction |
The table describes a support decision process. It does not mean every exception is resolved automatically or that all payment methods support the same steps.
Use an example without promising bank timing
Consider an illustrative rental with a 20-unit authorisation and a final rent of 3 units in the configured currency. For an eligible payment completed by a partial capture, the rental charge is 3 units and the unused authorisation is released. This is different from charging 20 units and issuing a 17-unit refund.
The distinction matters when explaining what the customer sees. Banking apps may present a pending hold and a final amount in confusing ways. Do not promise that every issuer will update its display immediately, or give one fixed hold-release deadline for every card and network.
A useful response is: “We have checked order [reference]. The recorded final rental charge is [amount and currency]. The payment record shows [verified outcome] for the original authorisation. If your issuer still displays a pending amount, use this reference when asking them to check it.” Replace each field only after verification.
Close genuine corrections with evidence
If the operator approves a refund, link the refund reference to the support case and original order. Record the amount, reason, operator and subsequent status. Avoid repeatedly clicking refund because the customer has not yet seen a bank update.
A missing permission, failed request or delayed status update should remain visible as an unresolved case. Confirm the outcome in Stripe rather than marking the case complete merely because someone submitted a request. Keep the operator’s correction policy separate from the technical ability to send a refund.
Prevent the next avoidable enquiry
Place clear information beside the reader: the authorisation amount if used, how rent is calculated, where returns are accepted and how to contact support. Train staff to say “authorisation” or “final charge” only when they know which state applies.
Review repeated enquiries alongside the station’s return records. If one cabinet produces a pattern of missing returns, investigate device behaviour. If payment records are correct but customers remain confused, improve the wording and order-query path.
Review CoreCharge’s reader-based rental approach, or request an order and payment support walkthrough using the rules planned for your project.
Implementation references checked on 16 October 2026. Deployment conditions and payment-method availability should be reconfirmed before ordering.