The first station should leave the acceptance session with a documented result, not just a video of a power bank popping out. A reliable handover proves that the shipped cabinet, its built-in Android application, physical reader, CoreCharge configuration and operator-owned Stripe account work together in the intended venue.
This manual is designed as a practical acceptance framework. It should be adapted to the exact cabinet and payment setup agreed for the project. It does not replace the reader manufacturer’s installation instructions or approval of the intended operating scenario.
Prepare the acceptance record
Give the record a version and date. Enter the operator, country, venue, currency, cabinet serial, reader model and serial, application version, payment environment and tariff version. Identify who performs the test, who approves it and who will retain the evidence.
Use an eligible market-specific reader: WisePad 3 is the reference mobile-reader option in many supported markets, while US projects use an appropriate US model such as M2. Confirm current availability in Stripe’s regional table. Confirm mechanical fit, reader supply, connection and permitted venue use before accepting the configuration.
Record only payment-account identifiers required for traceability. Secrets, private keys and customer card data do not belong in acceptance photographs, spreadsheets or delivery documents.
Check the hardware before collecting a payment
Inspect the cabinet, supplied power equipment, mounting, reader bracket, cables and removable power banks. Photograph the actual delivered unit and serial labels. Check that the installation location gives customers room to read the screen, reach the reader and return a unit.
Power on the station, confirm the correct operator branding and inspect the displayed tariff. Verify the agreed network connection. Where the design uses USB between Android and the reader, confirm that the supplied cable supports the required data connection; a cable that only charges is insufficient evidence of connectivity.
| Test | Evidence to retain | Acceptance condition |
|---|---|---|
| Reader connection | Reader identity and connection result | Intended reader works with this cabinet |
| Successful borrowing | Order reference, payment result and release event | One eligible payment journey releases one unit |
| Cancelled or failed attempt | Test result and customer message | No unintended release or duplicate order |
| Physical return | Unit recognition, return event and order duration | The correct rental closes according to agreed rules |
| Final rent | Tariff calculation and matching Stripe record | Amount and currency agree |
| Restart and recovery | Before-and-after state and reconnection result | Service resumes without unexplained order duplication |
Separate simulated tests from live acceptance
Use test tools for declines, cancellation, timeouts and repeat events before public operation. Stripe’s Terminal testing guide distinguishes simulated readers from physical test-card testing. The physical station still needs its own release and return checks.
After the test phase passes, conduct an authorised live acceptance journey on the intended account and reader. Follow the agreed controlled payment procedure. Test supported wallets in their actual supported environment rather than treating test-mode success as evidence of wallet acceptance.
For the agreed authorisation-based rental flow, verify the initial payment state, physical release, return time and final financial result. Check the authoritative payment record as well as the application screen. If the cabinet releases correctly but the final-payment action fails, the journey has not passed.
Record defects without hiding them in a video
For each failed step, record what happened, expected behaviour, affected serial number and responsible person. Assign an action and repeat the failed scenario after correction. Keep the earlier evidence so the handover shows what changed.
A useful video can follow one continuous journey from the tariff screen through borrowing and return. Supplement it with redacted order and payment screenshots. A cut between different cabinets or environments is unsuitable as the sole acceptance evidence for one shipped unit.
Finish with the operating handover
Confirm that the operator can log in, find the station, retrieve its rental record and identify a payment reference. Give the venue contact an opening checklist, support details and the steps for reporting a fault. Define how to pause new rentals while supporting existing borrowers.
Keep a small list of explicitly untested functions, such as a proposed network failover, cross-site return or offline behaviour. Validate them separately before advertising them. Acceptance of the first station becomes a reusable template, but each later unit still needs identity, connection and functional checks.
Explore CoreCharge POS-ready stations or request an acceptance pack matched to your country, reader and cabinet specification.
Implementation references checked on 16 October 2026. Deployment conditions and payment-method availability should be reconfirmed before ordering.