Our cards work with major hotel lock systems — but that sentence is a starting point, not a guarantee for your property. Compatibility is a conclusion you reach with evidence, and this guide sets out how to reach it.
Two cards can share a format, a thickness and a frequency and still behave completely differently at the same door. What separates them is the credential inside, the data written to it and whether the installed system was configured to accept that combination.
The check below is deliberately ordered. Each step narrows the possibilities, and the last step is the only one that actually proves anything.
Step one — describe the environment, not the card
Start by writing down what the property already runs. Room locks, staff doors, lifts, back-of-house areas, car park barriers and leisure facilities are often managed by different equipment, sometimes from different generations, and a credential that opens a guest room may be irrelevant at the spa turnstile.
Record which access points are in scope for this order and which are not. A compatibility question that is not scoped produces an answer that cannot be trusted, because it quietly assumes one credential covers everything.
Step two — identify the credential, not just the frequency
Frequency is the coarsest possible filter. A high-frequency credential operating at 13.56 MHz under ISO/IEC 14443 and a low-frequency credential operating at 125 kHz are not interchangeable, and knowing which one a property uses eliminates a large category of wrong answers immediately.
It does not, however, get you to a working card. Within high frequency there are several security tiers, from an entry tier through standard and high-security tiers to AES-secure credentials. A system configured for one tier will not necessarily read or trust another, and some systems will read a credential but refuse to act on it because the data it carries is not the data they expect.
The most reliable evidence at this stage is a current working credential. Its specification, or a technical read performed by someone accountable, tells you what the system is actually issuing today.
Step three — establish who encodes, and when
Encoding is where most compatibility surprises appear. Some properties encode on site at the front desk, using their own software and their own key data, and simply need blank credentials of the correct type. Others expect credentials to arrive pre-encoded with a defined numbering scheme or data layout.
These are different orders with different risks. If the property encodes on site, the physical card and its credential tier must be right, and nothing else about the data matters to us. If the credentials arrive pre-encoded, the data format, the sequence and the verification method all have to be agreed in writing before production, because an encoded run cannot be quietly corrected afterwards.
Step four — test a sample before the run
Nothing in the first three steps constitutes proof. They narrow the specification to a small number of plausible options; a physical test in the actual environment is what confirms it.
Test the sample at every access point in scope, not just at one guest room door. Test it with the staff who will use it, on the equipment they use daily, and record the result against a named approver. Where a property has more than one generation of equipment, test at each generation.
This step also protects the property commercially. A credential that has been tested and approved in writing changes the conversation if something later goes wrong, because the point of failure can be located instead of argued about.
When the answer is “we cannot confirm this”
Some access systems are closed, some are proprietary, and some are administered by a third party who will not release configuration details. That is a legitimate outcome, and the correct response is to stop rather than to guess.
If compatibility cannot be established, we say so before production instead of discovering it after delivery. An unusable run of credentials is a far more expensive problem than a delayed order, and it is the one outcome this entire process exists to prevent.
Start with the property, use case, destination and what is known about the installed access environment.
Three controls before release. Each stage is reviewed separately so an attractive product direction never substitutes for technical or operational confirmation.