Hotel Starter
40 / 40
100% · certified
Public certification report
40 scenarios tested. 40 passed.
Staycore achieved 100% coverage across the applicable scenarios in Revenue Protection Standard RPS-1.0.0—above the 97% minimum guarantee threshold.
Certification statement
A first-party product-control certification.
The Staycore Product & Controls Team executed 40 controlled automated scenarios against the 15 August 2026 certification snapshot, based on revision abb13ae6 plus the signed-in loyalty-member mobile-key policy. The matrix tests whether the product produces the defined preventive, detective, reconciliation, or audit outcome. It does not estimate financial losses or recovered money.
100% = 40 passed applicable scenarios ÷ 40 total applicable scenarios × 100
What “first-party” meansStaycore designed the standard, operated the test run, and issued this report.
Plan coverage
Every current hotel plan meets the threshold.
The four plans share the standard hotel operations feature set. Door-lock software controls are included in each plan; physical access outcomes require supported lock hardware to be installed, configured, and connected.
Hotel Growth
40 / 40
100% · certified
Hotel Business Plus
40 / 40
100% · certified
Hotel Enterprise
40 / 40
100% · certified
Scenario matrix
The complete public result.
Each row publishes the scenario ID, control area, required outcome, test statement, and result. Internal test implementation details are intentionally excluded. The same public matrix is available as machine-readable JSON.
| ID | Area | Outcome | Scenario | Result |
|---|---|---|---|---|
| RPS-ROOM-01 | Rooms & access | Prevent | Guest room entry requires an active room booking | Pass |
| RPS-ROOM-02 | Rooms & access | Prevent | Incorrect guest identity data is rejected at room entry | Pass |
| RPS-ROOM-03 | Rooms & access | Reconcile | A room move follows the current stay and retires the old route | Pass |
| RPS-ROOM-04 | Rooms & access | Prevent | A last-name-only session cannot retrieve a mobile key | Pass |
| RPS-ROOM-05 | Rooms & access | Prevent | A booking-token-only session cannot retrieve a loyalty-member mobile key | Pass |
| RPS-ROOM-06 | Rooms & access | Prevent | A later booking cannot reuse an older room credential | Pass |
| RPS-ROOM-07 | Rooms & access | Prevent | Front-desk room locks remain property scoped | Pass |
| RPS-ROOM-08 | Rooms & access | Prevent | Random room assignment does not reuse a reserved room | Pass |
| RPS-PAY-01 | Payments | Prevent | A property without Paystack cannot silently offer online prepayment | Pass |
| RPS-PAY-02 | Payments | Reconcile | A non-refundable prepay booking creates a payment link | Pass |
| RPS-PAY-03 | Payments | Prevent | Pay-now is rejected when the property has no payment processor | Pass |
| RPS-PAY-04 | Payments | Reconcile | Exact provider references create matched settlement cases | Pass |
| RPS-PAY-05 | Payments | Detect | Settlement imports classify matched and variance outcomes | Pass |
| RPS-PAY-06 | Payments | Detect | Duplicate provider references are detected | Pass |
| RPS-PAY-07 | Payments | Audit | A reconciliation resolution changes status and writes an audit record | Pass |
| RPS-PAY-08 | Payments | Prevent | A payment reference from another property remains unmatched | Pass |
| RPS-PAY-09 | Payments | Prevent | Corporate invoice payments reject duplicate references | Pass |
| RPS-PAY-10 | Payments | Audit | Corporate credit, debit, and write-off actions emit audit evidence | Pass |
| RPS-FNB-01 | F&B / POS | Detect | Expired POS drafts are hidden from the active work queue | Pass |
| RPS-FNB-02 | F&B / POS | Prevent | An expired POS draft cannot be completed | Pass |
| RPS-FNB-03 | F&B / POS | Prevent | A waiter cannot self-approve a forged manager discount | Pass |
| RPS-FNB-04 | F&B / POS | Reconcile | A KOT amendment keeps completed tickets closed and settles once | Pass |
| RPS-FNB-05 | F&B / POS | Prevent | Full-service tabs cannot settle while a KOT remains open | Pass |
| RPS-FNB-06 | F&B / POS | Detect | Completed unpaid tabs are surfaced and can be restored | Pass |
| RPS-FNB-07 | F&B / POS | Prevent | Offline POS drafts reject cross-owner update and completion | Pass |
| RPS-FNB-08 | F&B / POS | Prevent | POS terminal sync rejects refund and back-office events | Pass |
| RPS-FNB-09 | F&B / POS | Prevent | Operator PINs are verified without storing the raw PIN | Pass |
| RPS-FNB-10 | F&B / POS | Audit | Paid tabs leave the active queue but remain in manager history | Pass |
| RPS-INV-01 | Inventory | Prevent | Purchase-order transitions enforce separation of duties | Pass |
| RPS-INV-02 | Inventory | Prevent | Free-receipt GRNs require an owner or administrator | Pass |
| RPS-INV-03 | Inventory | Detect | Purchase price variance rules are enforced | Pass |
| RPS-INV-04 | Inventory | Reconcile | Supplier invoices reconcile to purchasing and receipt records | Pass |
| RPS-INV-05 | Inventory | Audit | Wastage adjustments retain a normalized reason | Pass |
| RPS-INV-06 | Inventory | Prevent | Inventory checks reject permissions outside the central role map | Pass |
| RPS-GOV-01 | Governance | Prevent | Managers can decommission locks but cannot delete bound access points | Pass |
| RPS-GOV-02 | Governance | Audit | Lock deletion preserves historical attendance and provider resolution | Pass |
| RPS-GOV-03 | Governance | Prevent | Hardware provisioning is atomic, idempotent, and secret-free | Pass |
| RPS-GOV-04 | Governance | Prevent | Mobile-key payloads exclude unneeded hotel credentials | Pass |
| RPS-GOV-05 | Governance | Prevent | Senior operational roles preserve inherited permission boundaries | Pass |
| RPS-GOV-06 | Governance | Audit | Property state snapshots retain stable audit identifiers | Pass |
Interpretation
What the result does—and does not—say.
It measures defined control outcomes
A pass means the controlled scenario produced its expected prevent, detect, reconcile, or audit outcome.
It is not a recovery percentage
100% scenario coverage does not mean all financial loss is recovered, or that every theft attempt is prevented.
Mobile key is identity-gated
A booking token alone cannot retrieve a mobile key. Retrieval requires a signed-in loyalty-member identity and the valid connected access workflow.
Connected operation matters
Supported integrations and lock hardware must be correctly installed and configured for their scenarios to apply in a customer environment.