“The reader accepts debit cards” does not establish how a variable-price rental will be settled. Canadian power-bank operators need to distinguish an eligible credit-card authorization from an Interac payment before choosing a deposit, refund or non-return policy. The difference affects the customer journey long after the card leaves the reader.
CoreCharge’s compatible Canadian reader configuration uses WisePad 3 with the station’s built-in Android controller and native Stripe Terminal SDK. Rental payments belong to the operator’s own local Stripe account. The platform connects orders, cabinet release, return events, pricing and operational records. The exact Interac business flow still has to be agreed and tested; generic reader compatibility is not evidence that a particular deposit model is ready.
The key financial distinction
Stripe’s Canada documentation says Interac authorizes and captures in one step. It does not support a hold followed by later capture, and a manual-only capture configuration declines Interac. Stripe’s manual-preferred option preserves that one-step Interac behavior while allowing supported non-Interac payments to follow a different path.
The same guidance requires an in-person Interac refund with the original card. A standard remote Dashboard or API refund is not available for these transactions. This is particularly relevant to a guest who borrows in one city and leaves before the rental adjustment is resolved. Canada Terminal transactions use CAD with the appropriate Canadian account and Location.
Translate the difference into an operating policy
| Policy question | Eligible credit-card flow | Interac planning implication |
|---|---|---|
| Can the initial amount be a hold? | May be possible with supported authorization and capture settings | Do not describe a captured payment as a temporary authorization hold |
| How is the final rental amount settled? | Check capture amount, timing and authorization conditions | Define a compatible commercial and technical flow before acceptance |
| How would money be returned? | Verify the applicable refund workflow | Plan for the cardholder to present the original card |
| What can support promise? | Only the verified outcome and process | Avoid promising an automatic remote refund after battery return |
Choose a model deliberately
One possible pilot decision is to enable only the verified payment methods compatible with the chosen variable-rental policy, while the Interac route remains under review. Another is to investigate a separately defined prepaid rental product. These are design options, not statements that every option is currently implemented or appropriate for every venue.
An upfront captured amount with a later adjustment sounds simple until the refund journey is examined. Who is present? Which station can process it? How will the customer find that station during business hours? What happens if they cannot return? Those questions should be answered before the operator publishes a promise about unused deposit balances.
Do not assume that changing a capture setting solves the entire rental model. The cabinet messages, order states, account permissions, customer terms and support procedure must follow the same decision. A financial operation that the payment method does not support cannot be created by a tariff setting.
Use a payment-method acceptance sheet
- Identify which method actually processed each controlled test, rather than relying only on a co-branded card’s appearance.
- Record the initial financial result and compare it with the customer-facing wording.
- Test release and return independently from the card transaction, using the same rental reference.
- Rehearse the applicable cancellation or refund procedure with an authorized operator.
- Approve the policy only when the financial result and customer explanation match.
Keep a separate outcome for “card accepted,” “battery received,” “rental ended” and “financial adjustment completed.” A customer could experience one without the next. Support should locate the original payment before attempting another operation, especially after an uncertain response or a repeated card presentation.
Make the venue conversation concrete
For an illustrative café pilot, ask staff to explain the selected payment policy in plain language before the first guest uses the station. Review English and French requirements for the actual location and audience. Put the help route where a guest can find it without searching their phone for a forgotten website.
CoreCharge can help translate the agreed payment policy into the rental configuration and acceptance plan. Local account eligibility, reader procurement and suitability for the intended staffed or unattended setting remain project checks. Review the physical reader solution or request a Canada payment-method review. Start with the desired tariff and refund promise; they determine what the implementation must prove.
Official references
Technical references checked on 16 October 2026. This is an implementation guide, not a report of a completed deployment in every market.