US Power Bank Rental Deployment: Stripe M2 Contactless Payments and H5 QR Checkout

Shared power bank rental in US hotels, restaurants, bars and event venues can offer two convenient starting points: tap a card or compatible mobile wallet at a Stripe M2 reader, or scan a station QR code to open a mobile web checkout. Customers can rent without downloading a dedicated app, while the operator manages both routes through one rental, device and settlement system.

The goal is a complete operational loop: authorize the payment, dispense the power bank, confirm its return, calculate the rental fee, settle the charge and provide a traceable receipt. This deployment plan explains how to connect those steps and which conditions to verify before launch.

1. Choose the venue and merchant model first

M2 is a candidate for attended or semi-attended venues where staff can help customers, such as a hotel reception, restaurant or staffed event area. Staff availability must be real throughout the service period. Stripe distinguishes these settings from fully unattended locations. Stripe’s guidance on retail environments

For a fully unattended station offering in-person card payments, Stripe currently supports the Verifone UX700 rather than M2. Unattended payments are generally available in the US and require the appropriate Terminal Location configuration. A QR-only online checkout can also be evaluated for a station without an in-person reader. Unattended reader documentation

US Terminal transactions use USD and require a US platform or connected account, with readers associated with US Locations. Account eligibility and the proposed business must be reviewed through Stripe’s actual onboarding process. US regional requirements

For a direct merchant deployment, the operator owns the eligible Stripe account and the customer relationship. Define who handles refunds, disputes, customer support and settlement reconciliation. A multi-merchant platform using Stripe Connect needs an additional onboarding and funds-flow design; adding a payment route alone does not create a revenue-sharing system.

2. Build two checkout routes around one backend

Contactless rental with Stripe M2

M2 connects to a phone or tablet through the Terminal iOS, Android or React Native SDK. Bluetooth LE is supported; USB is available with the Android SDK. M2 has no display and cannot be controlled directly through an H5 page, the Terminal JavaScript SDK or a server-driven integration. M2 setup, reader integration options

The station therefore needs a compatible host device and native application. Validate the exact operating system, SDK requirements and connection method rather than assuming any Android cabinet controller will work. The host screen should show the rental price, authorization amount, return policy and payment instructions.

Here, “tap” describes the customer’s contactless interaction with M2. Stripe’s Tap to Pay on iPhone or Android is a separate implementation in which a compatible merchant phone accepts contactless payments without an external reader. It can be considered for staff-assisted mobile service. Stripe Tap to Pay

App-free rental with H5 QR checkout

The customer scans the station QR code and opens a mobile web rental page. Show pricing, the authorization amount and return or overdue terms before payment. The checkout can use Stripe Checkout, or Payment Element with Express Checkout Element.

Apple Pay and Google Pay availability depends on the enabled payment methods, supported browser and the customer’s wallet setup. An Elements integration requires payment-domain registration and HTTPS. Keep a card-entry option available when a wallet button is absent. Express Checkout Element

3. Connect authorization, dispensing, return and settlement

Both entry points should create or resume the same kind of rental order. Link its order_id to the venue, station, slot, power bank serial number, payment attempt, PaymentIntent, authorized amount, rental fee, captured amount and device events.

Allow only one active payment attempt for a rental. When a customer switches between tapping and scanning, reconcile the original attempt before continuing. This prevents duplicate authorizations and two dispense commands for one customer.

1. Check availability and reserve a slot. Confirm station connectivity, usable power bank charge and available inventory before requesting authorization.
2. Create the order and present the terms. Display the same pricing, hold amount, return locations, overdue rules and loss policy on both routes. Record the customer’s consent.
3. Authorize through the selected route. Bind the payment attempt to the order. For separate authorization and capture, explicitly configure capture_method=manual.
4. Verify authorization on the backend. Retrieve the actual payment state and check that the valid authorization covers the required amount before issuing one idempotent dispense command.
5. Confirm dispensing before starting the rental clock. Validate the station event, slot and power bank serial number. A command acknowledgement alone is not proof that the customer received the power bank.
6. Confirm return and stop the clock. Accept return at supported stations on the same network. Match the serial number and use the trusted device return time.
7. Calculate and settle the rental. Apply the agreed pricing rules and capture the amount due within the valid authorization. Track return completion separately from payment settlement.
8. Issue a receipt and reconcile. Match payment, dispense, return, release and refund records. Route unresolved differences to an operations queue.

With manual capture, successful authorization produces requires_capture; the backend must also check amount_capturable. Waiting for payment_intent.succeeded before dispensing would wait until capture, which is the later settlement step in this design. Terminal payment collection

Verify Stripe webhook signatures, deduplicate events and process them asynchronously. Delivery order is not guaranteed. A browser success page must never be the sole authority for releasing a power bank. Stripe webhook documentation

4. Design the authorization and exception policy

For supported card payments, authorize before dispensing and capture the actual rental fee after return. A normal partial capture releases the unused authorization. A hold differs from collecting a deposit and later refunding it; the issuer controls when the release appears on the customer’s account. For illustration, a $30 authorization followed by a $4 rental results in a $4 capture and a $26 release. These figures illustrate accounting, not recommended pricing. Separate authorization and capture

Authorization windows differ between online and in-person payments; some Terminal authorizations last approximately two days. Store the actual capture_before information and schedule checks before expiry. Extended and incremental authorizations depend on eligibility and should not be assumed. Authorization validity

The operator should decide, before launch, how a rental approaching authorization expiry is handled under the disclosed and agreed terms. This may require an agreed early settlement or loss process. Do not automatically capture the full hold simply because a timer expires, or assume the original authorization can cover any higher fee. Later off-session charges require a suitable reusable payment method, consent and a recovery path when the charge fails.

Exception handling needs to cover the physical equipment as well as the payment:

• Dispense timeout: first check serial number, inventory and device events. A timeout is an unknown result, not confirmation that nothing was dispensed. Cancel the authorization only after confirming that no rental started; if funds were already captured, use a refund where appropriate.
• Duplicate return event: do not stop the clock twice or capture twice. A confirmed return followed by a settlement failure belongs in a payment exception queue; it must not extend the rental time.
• Reader or connectivity failure: pause new M2 rentals. Offer QR checkout only if the customer can access it and the station itself remains online. H5 cannot make an offline cabinet dispense.
• Return during an outage: retain local return events, upload them after connectivity recovers and stop billing at the trusted return time.

5. Make every order easy to recover

A customer who taps at M2 may never open a rental page on their own phone. Give that customer an order-recovery option on the host screen, such as a secure, single-use QR claim link, with optional email or SMS delivery of the receipt.

Protect subsequent order access with an appropriate token or authenticated flow. A bare order number or the last four card digits should not serve as an access credential.

Both routes should provide access to the rental status, pricing, supported return stations and customer support. The support console should place device events beside the payment record, making cases such as “authorized but not dispensed” and “returned but awaiting settlement” easy to investigate. Record the reason for any manual adjustment.

6. Pilot the complete journey before expanding

A practical starting point is a pilot at 10–20 venues with staff assistance. This is a proposed rollout size, not a claim of existing deployment results. Confirm connectivity, power supply, return capacity, replenishment and maintenance ownership at each venue.

Acceptance testing should include M2 cards and compatible wallets, H5 on iOS and Android, card declines, authorization failures, payment disputes, confirmed and uncertain dispense failures, cross-station returns, duplicate and out-of-order webhooks, authorization expiry, outage recovery, refunds and support-led order lookup.

Track authorization success, time from authorization to dispensing, dispense success, valid returns, reconciliation differences and support requests. Set acceptance thresholds with the operator using pilot evidence. Expand after the equipment, payment records and customer experience behave consistently together.

Frequently asked questions

Does one tap allow unlimited future charges?

No. A card_present payment is not automatically a reusable online card. Check whether a suitable generated_card was returned; some wallet transactions may not provide one. Later charges are card-not-present transactions and require the appropriate consent and failure handling. Saving payment details with Terminal

Must the customer wait for settlement after returning the power bank?

The interface should confirm a verified return and show that rental timing has stopped. Settlement can complete asynchronously. A payment processing failure should be handled by the backend without adding rental time after the return.

Can tapping and scanning share one rental platform?

Yes. Keep orders, pricing, device control, return recognition and support in one platform, with separate payment adapters for each checkout route. This gives the operator one consistent rental history instead of two disconnected systems.

CoreCharge can help evaluate the station, H5 rental flow, payment integration and operations backend as one deployment project. The exact hardware configuration and delivery scope should be confirmed for the operator’s venues and merchant setup. Explore CoreCharge POS rental stations