Confirm one provider reference creates at most one business transition and never a second eject command.
Implementation answer · H5 payment and device UAT
How to test an H5 shared power bank payment, unlock, return and refund flow
CoreCharge Cloud provides this field-level acceptance guide for shared power bank operators, agents and brand owners validating a browser-first rental flow. Test QR context, terms and pricing, payment authorization, provider callback, cabinet unlock, active order, return recognition, fee stop, refund or authorization-release handling and dashboard evidence as one traceable chain.
Direct answer
An operator should accept an H5 shared power bank flow only when the same masked station, slot, power-bank, order and provider references can be followed from QR entry through payment callback, device result, active rental, return, fee stop and refund or support disposition. Each success and failure path needs an expected state, an observable record, an owner and a dated UAT decision. A button click, a payment screen or a cabinet light alone is not sufficient evidence.
This is an implementation and acceptance page, not a claim of worldwide payment coverage. It does not describe consumer wallet top-ups, ordinary portable-charger purchases, UPS systems or home energy storage.
H5, native App and hybrid acceptance roles
The renter channel can change while the device, order, payment and support evidence contract remains explicit.
| Channel | Primary role | Dependencies to confirm | Minimum acceptance evidence |
|---|---|---|---|
| H5 browser flow | No-app QR entry for a scoped renter journey | Browser support, locale, terms, payment redirect or handoff, session recovery and support route | Versioned URLs or screenshots plus matched station, order, payment and device states |
| Native App | Installed renter channel where App-specific functions are required | Store build, account flow, permissions, deep links, payment route and release ownership | Build/version, tested device, route, expected/actual states and masked business references |
| Hybrid | H5 and App channels sharing selected business services | Channel handoff, identity/session rules, state parity and support ownership | The same order/device outcome is readable across the channels included in the project scope |
Acceptance boundary
CoreCharge does not claim that every H5 and App function is identical. The project UAT must identify which screens, payment routes, device commands and support actions are shared, channel-specific or not included.
Rental-state evidence chain
Each state should have an expected result, an observable record and an owner for exception handling.
| State | Renter or system view | Acceptance fields | Evidence owner |
|---|---|---|---|
| 1. QR and station context | The intended H5 route opens with the correct station and locale | station_ref, route, locale, environment, timestamp | Operator UAT owner |
| 2. Terms and pricing | Currency, pricing version, authorization/deposit rule, return rule and support entry are visible before confirmation | pricing_version, currency, locale, terms version | Operator business owner |
| 3. Payment initiation | The configured provider route opens or returns a readable error | payment_attempt_ref, order draft, route, initiated time | Merchant/operator and integration owner |
| 4. Authorization or charge result | A readable approved, declined, cancelled, pending or timeout state is returned | Masked provider reference, result class, amount/currency, received time | Provider/merchant evidence owner |
| 5. Callback classification | The business flow waits for the configured readable result and handles replay safely | callback_class, event reference, idempotency key, mapped order state | Integration UAT owner |
| 6. Unlock request and device result | The cabinet releases one power bank or shows an actionable failure | unlock_request_ref, station, slot, power-bank reference, acknowledgement, failure code | Device integration owner |
| 7. Active order | Rental time, assigned device and return guidance are readable | Masked order ID, device assignment, start time, pricing version, state | Operator/order owner |
| 8. Return event | The tested station identifies the returned device and slot, or records an exception | return_event_ref, station, slot, device, received time, exception | Device and support owner |
| 9. Order close and fee stop | The renter and dashboard show the configured final rental state | Order transition, fee-stop event, final amount/currency, closure time | Order and reconciliation owner |
| 10. Refund or authorization-release handling | A known requested, pending, completed, declined, partial or manual-review state is shown when supported | refund_ref, reason, amount/currency, provider state, owner | Merchant/provider and support owner |
| 11. Support disposition | The renter receives a case reference or next step without a timing guarantee | Masked case ID, linked business references, decision, reviewer, disposition time | Operator support owner |
Field-name boundary
The code-style names above are UAT record labels, not a promise of a public API schema. Exact payload fields, provider semantics and device commands are confirmed for the selected project and evidence tier.
Payment and refund status evidence
Use these meanings as acceptance categories only after the selected provider, merchant entity and project route expose a readable result.
| Acceptance category | Trigger or meaning | Fields to retain | Owner and evidence state |
|---|---|---|---|
| Initiated | The renter starts the configured payment or authorization route | Attempt reference, order draft, amount/currency, route, initiated time | Operator/integration · CUSTOM_REVIEW_REQUIRED |
| Authorized or preauthorized | The provider returns a readable authorization result where the project uses that model | Masked provider reference, authorized amount/currency, provider state, received time | Merchant/provider · CUSTOM_REVIEW_REQUIRED |
| Captured or charged | A readable charge/capture result is mapped to the intended business transition | Masked reference, amount/currency, callback class, mapped order state | Merchant/provider and order owner · CUSTOM_REVIEW_REQUIRED |
| Deposit or hold | A project-specific hold/deposit state is displayed only when the route supports it | Rule version, masked reference, amount/currency, known provider state | Merchant/provider · CUSTOM_REVIEW_REQUIRED |
| Refund requested | An operator or configured workflow creates a traceable request | Reason, amount/currency, linked payment/order, request owner and time | Operator support · CUSTOM_REVIEW_REQUIRED |
| Provider pending or manual review | No final outcome is inferred while a readable request remains unresolved | Known state, last reviewed time, owner, next action and masked reference | Merchant/provider and support · CUSTOM_REVIEW_REQUIRED |
| Completed, partial, declined or released | The final displayed category follows the readable provider result and operator policy | Result class, amount/currency, result time, reviewer and reconciliation state | Merchant/provider and reconciliation owner · CUSTOM_REVIEW_REQUIRED |
What this table does not prove
It does not prove PSP onboarding, merchant eligibility, settlement, a fixed refund time or availability in any country. Provider documentation and project evidence must identify applicability, version and last review date.
UAT record fields
Every scenario should be reproducible without publishing payment credentials or renter identity.
| Field | Record | Why it matters | Public boundary |
|---|---|---|---|
| Scenario and expectation | Scenario ID, environment, precondition, expected business state and reviewer | Separates an intended test from an unexplained screenshot | Do not present a test as a live-market guarantee |
| Rental context | Locale, currency, pricing version, deposit/authorization rule and support route | Shows which displayed contract was actually tested | Provider and legal conclusions remain external |
| Device chain | Masked station, slot and power-bank references, command and acknowledgement | Connects payment outcome to physical eject and return behavior | Exact compatibility remains model-specific |
| Order chain | Masked order ID, state transitions, start/end timestamps and exception code | Shows whether one event created one controlled business transition | No personal data or unrestricted logs |
| Payment chain | Masked provider reference, callback class, authorization/charge/refund/release state | Supports idempotency and reconciliation review | No token, credential or provider approval claim |
| Evidence and disposition | Timestamp/timezone, redacted screenshot or log, owner, actual result and final disposition | Makes the exception review auditable | Redact contact and payment secrets |
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.
Ten minimum UAT cases
Run each case with dated expected/actual evidence. Provider-specific actions remain subject to merchant and project confirmation.
| Case | Controlled action | Expected evidence | Failure owner |
|---|---|---|---|
| UAT-H5-01 · QR context | Open a valid code in a fresh browser session | Correct station, locale, environment and terms/pricing version | Operator configuration owner |
| UAT-H5-02 · Invalid or stale QR | Open an invalid, disabled or mismatched route | No rental starts; an actionable error and support path are shown | Operator/support owner |
| UAT-PAY-01 · Decline or cancel | Use the provider-approved test path for a non-approved result | Readable failure/cancel state; no unlock request and no active order | Merchant/provider and integration owner |
| UAT-PAY-02 · Readable success callback | Use the approved test route for the intended positive result | One mapped business transition linked to the masked provider and order references | Integration/order owner |
| UAT-DEV-01 · Payment success, no eject | Exercise a controlled unavailable/offline/timeout device condition | Payment, callback, order, unlock command and device failure remain separate and traceable | Device integration and support owner |
| UAT-PAY-03 · Duplicate callback | Replay the same provider event in the test environment | One business transition, no second unlock command and an auditable duplicate record | Integration owner |
| UAT-ORD-01 · Active rental | Complete the configured positive unlock path | One assigned power bank, readable start time, pricing version and active order state | Order/device owner |
| UAT-RET-01 · Normal return | Return the assigned device to an accepted station/slot | Return event, linked device/order, fee-stop event and closure state | Device/order owner |
| UAT-RET-02 · Return exception | Exercise a controlled full/offline/unrecognized return path | No false closure; last-known event, case owner and reconciliation path are recorded | Device/support owner |
| UAT-REF-01 · Refund or release handling | Create an allowed test request after a defined exception | Requested/pending/final state, amount/currency, owner and linked masked references without a timing promise | Merchant/provider and support owner |
Abnormal-order coverage
A useful UAT pack proves that failures remain readable and do not become false success events.
Keep payment, order, command, acknowledgement and support states distinguishable.
Preserve the last-known event and create a reconciliation path instead of promising automatic closure.
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.
Field-level evidence anchors
This public page defines what a buyer should request and review. It does not publish client records or claim a live provider deployment.
Fields: environment, URL/build, locale, pricing/terms version, station context and captured time.
Status: CUSTOM_REVIEW_REQUIRED · Owner: operator product owner · Date: project test date.
Fields: provider/merchant applicability, masked reference, amount/currency, result class, callback class and mapped order state.
Status: CUSTOM_REVIEW_REQUIRED · Owner: merchant/provider and integration owner · Date: project test date.
Fields: station, slot, power-bank reference, request, acknowledgement, timeout/failure code and firmware/protocol version.
Status: CUSTOM_REVIEW_REQUIRED · Owner: device integration owner · Date: project test date.
Fields: station/slot, returned device, event time, order transition, fee-stop record and exception state.
Status: CUSTOM_REVIEW_REQUIRED · Owner: device/order owner · Date: project test date.
Fields: reason, amount/currency, masked linked references, known result, support owner, review time and final disposition.
Status: CUSTOM_REVIEW_REQUIRED · Owner: merchant/provider and operator support · Date: project test date.
Fields: case ID, version, precondition, expected/actual state, timestamp/timezone, redacted screenshot/log, pass/fail and reviewer.
Status: CUSTOM_REVIEW_REQUIRED · Owner: named UAT lead · Date: acceptance review date.
Evidence-tier boundary
Only evidence with a stated environment, version, date, owner and public authorization can be described as verified public. Internal records remain internal; provider and market applicability stays custom-review-required until the selected merchant route is documented and tested.
H5, payment and UAT FAQ
These answers describe validation method, not payment-provider approval or market compliance.
Can an H5 rental flow work without a native App?
An H5 flow can support a browser-first scan-to-rent journey when the tested market, payment route, device protocol and support process work together. This does not mean H5 is always preferable or that every App function is available in a browser.
What should happen if payment succeeds but the cabinet does not eject a power bank?
Keep the payment result, dispense command, cabinet response, order state and support owner separate. Create a traceable exception instead of marking the rental successful or promising an automatic refund.
How should duplicate payment callbacks be tested?
Replay the same masked provider reference and confirm idempotency: one business transition, no second eject command and an auditable duplicate-event record.
When should charging stop after a power bank is returned?
The tested order should stop according to the configured readable return event and order-closing rule. A physical insertion alone is not sufficient when the system has not recognized the return.
Who controls refund or deposit-release timing?
The displayed state depends on the operator workflow, selected provider and readable integration result. CoreCharge does not guarantee provider approval, settlement or a universal refund or authorization-release time.
What evidence should an H5 payment and refund UAT retain?
Retain a scenario ID, expected and actual state, timestamp and timezone, masked station, slot, device, order and provider references, callback classification, owner, screenshot or redacted log and final disposition.
Can H5 and a native App use the same rental backend?
They can share selected device, order, payment and support services when the project is configured that way. UAT must still prove channel handoff, state parity and which screens or actions remain H5-specific or App-specific.
What must be tested before an H5 rental pilot goes live?
At minimum test QR context, terms and pricing, decline or cancel, readable payment result, payment success with no eject, duplicate callback, active rental, normal return, return exception and refund or authorization-release handling. Record expected and actual evidence for each case.
Define a testable rental and support contract.
Share the country, merchant entity, proposed PSP and currency, rental/pricing rules, station SKU and protocol, H5/App scope, refund policy, UAT environment and required exception states. These inputs define the review scope; they do not establish provider approval.