Answer first: require an end-to-end acceptance test for every station model and firmware family. A model is compatible only when the SaaS can uniquely identify the cabinet, map every slot, report real availability, dispense the intended power bank, recognize returns, close orders, process delayed or duplicate messages safely, raise actionable alerts, and preserve audit evidence through offline and update scenarios. A successful network connection or one demonstration rental is not sufficient proof.
Buyers often treat compatibility as a connector question: does the station use 4G, Wi-Fi, MQTT, or an HTTP API? Transport is only one layer. A station may connect and still misreport slot numbers, accept the wrong device identity, lose a return event, duplicate a dispense acknowledgement, or run firmware that the SaaS cannot update or diagnose. Compatibility is a contract among hardware, firmware, messaging, cloud services, payment state, customer flow, and field support.
The slot count matters because each physical layout needs a verified logical map. Do not assume that a protocol working on an eight-slot unit automatically covers a twelve- or twenty-four-slot controller. Test every supplied controller board, firmware version, lock type, power-bank identity scheme, communication module, and regional network configuration.
1. Device and slot identity
Each cabinet needs a unique physical and logical identity, and every slot must map consistently across firmware, API, dashboard, field app, and audit log. NIST's IoT capability catalog includes unique device identification and identification of loaded software as core capabilities [1]. It is cybersecurity guidance, not a rental specification, but it supports a basic procurement requirement: the buyer must know which device and software produced each event.
Verify serial number, model, controller revision, communication module, SIM or network profile, firmware version, slot count, slot numbering, and power-bank ID format. Swap units between slots and confirm that the SaaS follows the unit rather than only the position. Test duplicate IDs, unknown IDs, and a replaced controller. The system should reject or quarantine ambiguous mappings rather than silently attaching them to the wrong order.
2. State model and telemetry
Agree on explicit states for ready, charging, empty, locked, open, disabled, faulted, offline, and maintenance. Define which party calculates “rentable” and “return-capable.” A raw occupied flag is not enough.
For each state change, specify event name, schema version, device time, server receipt time, station and slot identity, power-bank identity, reason code, sequence or idempotency key, and acknowledgement behavior. RFC 3339 provides an interoperable timestamp format with UTC offsets [2]. Store unambiguous event time while retaining the station time zone for local operations.
3. Messaging behavior
MQTT 5.0 is an OASIS publish/subscribe messaging standard designed for constrained and IoT environments [3]. A supplier may use MQTT, HTTP, or another documented protocol; protocol name alone does not prove reliability. Test reconnects, retained or stale messages, duplicate delivery, delayed delivery, out-of-order events, session expiry, authentication failure, and bandwidth loss.
Create a deterministic rule for each case. A duplicate dispense acknowledgement must not create a second rental. A delayed return message must not reopen a closed order. An offline cabinet should not appear available indefinitely. The system should expose last-seen time and data freshness so the customer map and field team can distinguish current from stale status.
4. API and version contract
Request machine-readable API documentation. OpenAPI defines a language-agnostic description for HTTP APIs so humans and computers can understand service capabilities without source-code access [4]. If HTTP APIs are used, document endpoints, authentication, schemas, error codes, pagination, rate limits, retries, idempotency, versioning, deprecation, and sandbox behavior.
Freeze the acceptance version. A supplier's future API should not be assumed compatible. Define how firmware and SaaS releases are paired, how breaking changes are announced, how long old versions are supported, and how rollback works. Test a mixed fleet during upgrades so one model is not stranded.
5. Rental and payment state
Run the complete customer sequence: scan, price disclosure, authentication if applicable, payment initiation, successful authorization or charge, dispense command, physical release, acknowledgement, active rental, return, order closure, fee stop, receipt, refund or authorization release, and support evidence.
Then inject failures. Test payment success with dispense failure, dispense success with delayed payment callback, user cancellation, duplicate callback, return during network outage, and manual support correction. Payment handlers should tolerate retries and out-of-order events without duplicating business side effects; verify the exact behavior against the selected provider's current documentation.
6. Offline and recovery behavior
Disconnect the station during idle, dispense, and return states. Define whether rentals are blocked, queued, or permitted under a controlled offline mode. Verify how the device stores events, how many it can retain, how it orders replay, and how conflicts are resolved after reconnect.
Customer-facing behavior must be explicit. Do not show a stale station as available. Do not stop or continue billing solely from an unverified assumption. Define a support path for a physically returned unit whose digital closure is delayed. Consumer and payment treatment requires target-market legal and provider review.
7. Operations, security, and updates
Test remote configuration, authorized access, credential rotation, logs, alerts, firmware signing or authenticity controls, staged updates, rollback, and recovery from interrupted updates. NIST's IoT baseline covers configuration, data protection, interface access, software update, and cybersecurity-state awareness [1]. Use it as a capability prompt, not as a claim that the product is certified or compliant.
Confirm which telemetry is visible to operator, agent, merchant, and support roles. Minimize personal and payment data. Export a device and order audit trail without exposing secrets. Record who changed a configuration or manually corrected an order.
8. Model-by-model acceptance matrix
Create one row for every combination actually purchased: slot count, cabinet model, controller, firmware, communication module, power-bank type, payment flow, country network, and SaaS release. Mark each test pass, fail, blocked, or not applicable, with evidence and retest date. A 16-slot OEM variant without a public product page still requires the same matrix; never infer support from a neighboring 12- or 24-slot model.
Do not accept screenshots as the only proof. Retain event IDs, redacted logs, API payload schemas, station video for physical actions, order records, and observed before-and-after slot states. Redact tokens, signatures, customer data, payment details, and real QR values.
Compatibility is complete only when normal and failure paths agree across the physical station and the SaaS. This evidence protects both procurement and launch: it tells the buyer exactly which models, versions, networks, and payment flows were tested, and where further integration work remains.
Evidence date and limits
Evidence reviewed through 2026-08-09. The following limits are part of this buyer guide:
- MQTT, OpenAPI, RFC 3339, and NIST documentation support technical principles; none certifies a specific CoreCharge or OEM station.
- The checklist does not claim support for a model or firmware until model-specific evidence exists.
- Cybersecurity, radio, electrical, product, payment, privacy, consumer, and data-residency requirements vary. Verify target-country requirements before publication and deployment.
- No uptime, security, compatibility, certification, or payment-acceptance guarantee is made.
Related CoreCharge guides
- shared power bank rental software integration checklist
- power bank rental software features
- shared power bank rental system buyer faq
- products 4 slot.html
- products 6 slot.html
- products 8 slot.html
- products 12 slot.html
- products 24 slot.html
- Previous guide in this capacity cluster
- Next guide in this capacity cluster
Sources
1. U.S. National Institute of Standards and Technology - NIST IoT Device Cybersecurity Capability Catalog / NISTIR 8259 series (accessed 2026-08-09). device identification, configuration, data protection, interface access, software update, and cybersecurity-state awareness are core IoT capability areas. 2. IETF / RFC Editor - RFC 3339: Date and Time on the Internet: Timestamps (accessed 2026-08-09). interoperable, unambiguous Internet timestamps with UTC offsets. 3. OASIS - MQTT Version 5.0 (accessed 2026-08-09). MQTT is a lightweight client-server publish/subscribe messaging transport designed for constrained and IoT contexts. 4. OpenAPI Initiative - OpenAPI Specification v3.1.1 (accessed 2026-08-09). a standard, language-agnostic interface description can document HTTP API capabilities and schemas.