01 / Feature · access
One access layer for every gate.
Orchestrate Nokē, BearBox, PTI Cloud, OpenTech and Paxton from one place — auto-overlock overdue units, auto-restore the moment they pay, and see every entry on one timeline. StoreBay orchestrates the hardware you already own — software only.
◐ Vendor connections — coming soon
02 / One layer over your hardware
Software orchestration, no first-party hardware
Each site will be able to run a different provider — presented as one console, with one credential model and one event shape. Nokē is next on our build order; the other vendor connections follow.
Illustration of planned functionality: five sites each running a different access-control vendor — Camden Lock on Nokē, Bristol Docks on BearBox, Leeds North on PTI Cloud, Glasgow East on OpenTech and Cardiff Bay on Paxton via a site bridge — presented as one console, with Nokē named as the next vendor connection to be built.
Nokē◐ Coming soon
Smart-entry credentials + access events.
BearBox◐ Coming soon
Smart-entry / site controllers.
PTI Cloud◐ Coming soon
PTI StorLogix Cloud access control.
OpenTech◐ Coming soon
OpenTech INSOMNIAC access control.
Paxton◐ Coming soon
Paxton Net2, via a per-site bridge.
03 / Credentials that will follow the balance
Access will follow the agreement, automatically
Once a vendor is connected, credentials are issued, suspended and revoked in step with billing and the agreement lifecycle — never a manual gate-code errand.
Issue
A credential is created at move-in, the moment the agreement is signed and the first payment clears — no gate-code errand, no spreadsheet of PINs.
Suspend
Overdue past the rule you set, and the credential is suspended rather than deleted — so restoring it is instant, and the history stays intact.
Revoke
Move-out revokes it in the same minute the agreement ends, so a former customer never keeps working access to a unit they have left.
04 / Overdue in, overlock out — automatically
Delinquency-wired, and it restores itself
The collections engine already computes exactly when a unit should overlock and when it should restore — wired straight to billing, not a manual step. Once a vendor is connected, that decision reaches the lock automatically.
Illustration of planned functionality: the schedule that decides an overlock — invoice issued on day zero, payment due day five, reminder and late fee day ten, overlock decision day fourteen — then the event chain where an overdue invoice opens a collections case and applies an overlock through the site's vendor, and a collected payment releases it the same minute.
05 / Every gate, one timeline
One cross-vendor event timeline, not five consoles
Every credential grant, suspension and entry event across every connected vendor will land on one unified timeline, instead of five disconnected vendor consoles.
Illustration of planned functionality: five separate vendor consoles, each with its own event vocabulary, contrasted against one normalised StoreBay timeline where access grants, an overlock, a site-bridge outage and a restore all appear in one feed with a consistent event name.
06 / Common questions
What operators ask about access
The honest answers, including the ones about what is not built yet.
No obligation · UK-based support · migrations handled