Confirm no unlock or success state is created without the configured readable business result.
Buyer answer · Rental workflow UAT
How should an operator test H5 rental, payment, return and refund states?
Test the rental journey as a chain of readable business states: QR entry, terms, payment handoff, authorization result, unlock command, active rental, return recognition, order closure and refund-support handling. Store redacted evidence for both success and failure paths.
Direct answer
Use H5 when a browser-first scan-to-rent path and low download friction suit the pilot. Use an App when the operator needs a persistent account experience or App-specific functions. In either channel, acceptance depends on explicit order, payment and device states, not on a button click or a visually successful screen alone.
Rental-state evidence chain
Each state should have an expected result, an observable record and an owner for exception handling.
| State | Renter view | Operator evidence | Failure question |
|---|---|---|---|
| Scan and identify | Correct station entry and language | Masked station ID, route, timestamp and environment | Did the QR lose station or market context? |
| Terms and pricing | Readable rules before authorization | Versioned copy and expected charge/deposit rule | Was the tested rule different from the displayed rule? |
| Payment handoff | Provider route opens or returns a readable error | Provider reference, callback state and masked order ID | Was the order created before a valid provider result? |
| Unlock | Battery release or a clear failure message | Command, station, slot, power-bank ID and response state | Did authorization succeed but device release fail? |
| Active rental | Order time and return guidance | Order state, device assignment and event timestamps | Did the renter and dashboard show different states? |
| Return | Return accepted or actionable exception | Station, slot, returned device and closure state | Was the device inserted but the order left open? |
| Refund support | Status and support path, not a guarantee | Reason, provider status, operator decision and audit trail | Who owns a pending, declined or partial outcome? |
Six UAT steps
Run positive and negative scenarios in a controlled environment before making a public launch claim.
Lock the environment and configuration
Record market, URL or App build, station model, firmware, device protocol, payment route, pricing version and test owner.
Verify QR and session context
Open a fresh session and a returning session. Confirm the route keeps station, language and intended renter context without exposing secrets.
Exercise authorization and unlock
Test approved, declined, cancelled, timeout, duplicate callback, no available battery and unlock-failure paths separately.
Verify return and closure
Test normal return, wrong station if applicable, full station, unreadable device, delayed event and a return event received after support intervention.
Review refund-support handling
Confirm the workflow can distinguish requested, under review, provider pending, completed, declined and manual follow-up states when the integration supports them.
Package redacted acceptance evidence
Store expected versus actual state, masked identifiers, timestamp and timezone, relevant redacted fields, screenshot, reviewer and disposition.
Abnormal-order coverage
A useful UAT pack proves that failures remain readable and do not become false success events.
Keep order, payment and device-command states distinguishable for support.
Provide an operator path for reconciliation instead of promising automatic resolution.
Display the known status and owner; do not guarantee the provider's final outcome or timing.
Do not treat an opaque, invalid or missing response as business success.
Link the masked order, device, station, renter contact channel and decision history without exposing personal data publicly.
Redaction boundary
Do not publish payment tokens, account credentials, full order/device identifiers, renter names, phone numbers, email addresses or unrestricted logs. Screenshots and payload excerpts must be purpose-limited and redacted.
H5, payment and UAT FAQ
These answers describe validation method, not payment-provider approval or market compliance.
Should an operator test H5 and App flows the same way?
Use the same business-state checklist for scan, authorization, unlock, active rental, return and support, but test browser, deep-link, session, notification and account behaviors separately for each channel.
Does a successful UAT prove payment approval or a final refund outcome?
No. UAT proves only the tested configuration and scenarios. Provider onboarding, production approval, settlement and refund outcomes remain subject to the selected provider, operator rules and live environment.
What evidence can be shared without exposing renter data?
Share scenario IDs, timestamps, masked station, device and order references, state transitions, redacted callback fields, screenshots without personal data and reviewer decisions. Do not publish payment tokens, full identifiers, contact details or credentials.
When is a rental flow ready for a controlled pilot?
When required positive and negative scenarios have readable outcomes, owners are assigned for exceptions, critical defects are resolved or accepted, and the operator understands remaining provider and market dependencies.
Define a testable rental and support contract.
Share the target channel, payment route, station protocol and required exception states for a scoped UAT review.