A successful test payment proves one part of a rental integration. Public launch requires evidence that the correct operator receives payments, the physical cabinet releases and recognises power banks, the final rent is handled correctly, and local staff know what to do when something fails.
Use a staged go-live process for a CoreCharge station with a compatible physical Stripe reader and built-in Android controller. The operator retains its local Stripe account; CoreCharge supplies the agreed software integration, rental-order logic, device control and operating interface. The launch decision belongs to the tested deployment, not to a generic product demonstration.
Gate one: approve the configuration sheet
Record the operator, country, currency, venue address, cabinet serial, reader model and serial, software version and tariff version. Identify the person authorised to approve payment settings and the person who can reach the machine. Check that the ordered equipment matches the installation scenario, including power, mounting and data connectivity.
Confirm that the operator’s account is ready for the proposed Terminal activity and that the reader is appropriate for that market and use. The fact that a reader can connect in a workshop does not approve every public or unattended venue arrangement.
Gate two: separate the payment environments
Test and live configurations need separate records. Stripe explains that objects in one environment are not accessible in the other, and server credentials require secure handling. Review the official API key guidance. Use the minimum integration permissions agreed by the technical team, and transfer sensitive configuration through the approved secure channel.
Do not place restricted keys inside cabinet software, installation PDFs or customer chats. The server-side payment service supplies the Android application with the connection material needed for the reader. Keep ownership, access scope and credential rotation responsibilities clear.
| Control | Evidence before public use |
|---|---|
| Correct operator | Live payment appears in the intended operator account |
| Correct venue | Reader and Location match the actual installation |
| Payment events | Verified production callbacks update the intended rental order |
| Rental rules | Displayed tariff agrees with the calculated final rent |
| Reversal path | Cancellation or refund permissions and result have been checked |
| Support ownership | Named contacts can identify the station and retrieve its order |
Gate three: finish negative tests first
In the test environment, exercise a decline, customer cancellation, timeout, interrupted connection and repeated delivery of the same payment event. The expected result must include the cabinet: no duplicate release, a comprehensible customer message and an order that support can explain.
Stripe provides simulated-reader and physical-card tools in its Terminal testing documentation. Mobile wallets cannot be tested through Terminal test mode, so that environment cannot establish a complete Apple Pay or Google Pay acceptance result.
For the rental layer, add a returned unit, a different compatible return slot, an unavailable release slot and a cabinet restart. Document which behaviours are validated and which remain outside the agreed launch scope. Do not extrapolate offline operation from an online test.
Gate four: run one controlled live journey
During a planned acceptance session, use the approved live setup and an authorised participant’s real payment method. Follow the operator’s agreed small-value test or authorisation procedure; never use test card numbers against live processing. Record the start time, station identifier and resulting order reference without capturing sensitive card details.
Complete the physical borrow and return. Check the final rent and the actual Stripe outcome. Where the agreed flow uses eligible authorisation and capture, confirm the result appropriate to that order. A screenshot of an approved reader screen alone does not demonstrate a completed rental.
If customer callbacks are involved, check production signature verification and the resulting order state. Stripe’s event endpoint guidance describes the payment-event layer; the operator also needs evidence of the corresponding cabinet action.
Release the site with a recovery plan
Give the venue an opening check, a support contact and clear instructions for pausing new borrowing. Establish how existing borrowers receive help if the cabinet loses connectivity. Assign someone to review the first operating period and reconcile the initial live orders.
Public launch should follow signed acceptance of the actual station, not a deadline that leaves unexplained payments or missing return events. Retain a record of the approved configuration so a later reader replacement or tariff change can be checked against it.
See CoreCharge reader-equipped rental stations or request a go-live acceptance plan for your country, hardware and venue.
Implementation references checked on 16 October 2026. Deployment conditions and payment-method availability should be reconfirmed before ordering.