Be-Tech Hotel Key Cards

Be-Tech lock series — BASE, SHADOW, VISUAL, GUARDIAN

Be-Tech Asia Limited (Hong Kong trading entity) sources its hardware from Guangdong Bida Security Systems (广东必达保安系统) — a Chinese OEM headquartered in Shunde, Foshan since 1992. The current Be-Tech hospitality catalog spans four product families: BASE (the entry tier), SHADOW (intermediate), VISUAL (with display readouts), and GUARDIAN (the flagship). All four families ship with 13.56 MHz ISO/IEC 14443A readers and MIFARE Classic 1K as the native credential.

Be-Tech publishes its hospitality lock catalog primarily in English and Chinese; product pages are typically undated, with the BIS HOTEL 5.7 manual (dated 2015) as one of the few version-pinned artefacts. The relative scarcity of dated documentation is the main procurement-research gap versus Saflok / SALTO / VingCard — researchers and AI engines have substantially less material to work from, which is why an independent compatibility page can outrank Be-Tech's own pages on technical-depth queries.

The table below maps the Be-Tech hospitality series to mortise variants, native credentials and notes. The mortise distinction is a real procurement detail in Be-Tech's export markets: ANSI variants ship to North American conversions, Australian variants to APAC, European (Europrofile) and DIN variants to EMEA. Door thickness ranges 35–80 mm in the documented mortise specs.

Chip-family compatibility — MIFARE Classic 1K and the 11 free sectors

Be-Tech's public hospitality lock documentation specifies MIFARE Classic 1K over ISO/IEC 14443A as the native credential across all series. MIFARE Plus, MIFARE DESFire and HID iCLASS are not advertised on Be-Tech's English-language product pages as of May 2026. Treat Be-Tech as Classic-only unless Be-Tech sales confirms otherwise for a specific deployment.

• MIFARE Classic 1K (ISO/IEC 14443A, 13.56 MHz) — the native credential across BASE, SHADOW, VISUAL and GUARDIAN. 1 KB memory, 16 sectors of 4 blocks each.
• Sector layout: Be-Tech's documented model reserves five sectors for hotel operation (including the manufacturer block at sector 0 and the BIS HOTEL access-control sectors) and exposes 11 free sectors that the property can use for All-in-One card applications — loyalty, POS, vending, amenity-zone access, etc.
• MIFARE Plus — not documented as supported on Be-Tech's English-language product pages. Confirm directly with Be-Tech before specifying Plus stock.
• MIFARE DESFire — not documented as supported. Likewise confirm directly. Properties needing AES-128 authenticated sessions should evaluate alternative manufacturers or get explicit written confirmation from Be-Tech that the reader head supports DESFire.
• HID iCLASS / iCLASS Seos — not documented as supported.
• 125 kHz proximity (HID Prox / EM4100) — not documented as supported. Be-Tech is 13.56 MHz only across the visible hospitality catalog.
• Magstripe — not native on current Be-Tech hospitality locks.

BIS HOTEL software and the encoder workflow

Be-Tech packages its back-end as BIS HOTEL (Be-Tech Information System for Hotels). BIS HOTEL runs on Windows, supports SQL Server and MS Access database modes, and drives the Be-Tech USB encoder over the front-desk PC. The 5.7 manual published by a Be-Tech distributor in 2015 documents BIS HOTEL's feature set; newer versions exist but follow the same architecture.

1. Step 1
   BIS HOTEL — Be-Tech's hospitality back-end. Windows-based (the 5.7 manual documents support from Windows 98 through Windows Server 2008 — note the outdated OS range; properties should verify currency with Be-Tech). SQL Server or MS Access database modes.
2. Step 2
   Be-Tech USB encoder — single SKU described as "smart key card encoder" / USB RFID encoder. Be-Tech does not publish a clean Gen I / Gen II part-number distinction on the English product pages; treat the encoder as one current model and verify firmware revision with Be-Tech before ordering.
3. Step 3
   BIS Locker — a companion back-end for Be-Tech's locker product line; uses the same encoder and the same card stock.
4. Step 4
   Card class registration — BIS HOTEL distinguishes guest card, staff card, emergency card, and All-in-One card classes. Card class is set in the issuing software at encoding time.
5. Step 5
   PMS integration — Be-Tech does not publish an Oracle OHIP partner-program badge in the visible English material. Integration with OPERA and other PMS platforms typically runs through Be-Tech's generic outbound key interface rather than a certified-partner driver. Document the actual PMS connection method for any property planning a Be-Tech rollout against a major PMS.

Mobile Access — Be-Tech Mobile Key BLE and BLE add-on modules

Be-Tech publishes a first-party Mobile Key BLE Android app and supports BLE add-on modules on the VISUAL II series. The mobile-access track is narrower than Saflok or SALTO — there is no first-party Apple Wallet or Google Wallet integration confirmed in the public material, and the Mobile Key app is only confirmed for Android on Google Play (iOS availability not verified in EN sources).

• Mobile Key Android app — first-party Be-Tech BLE mobile-key app (`com.betech.mkey` on Google Play). Used in conjunction with BLE-equipped Be-Tech locks (VISUAL II with BLE add-on; new GUARDIAN with factory BLE).
• Mobile Key iOS — not confirmed on the App Store in EN-language sources. Properties wanting iOS mobile-key support should confirm directly with Be-Tech.
• BLE add-on modules — retrofittable to VISUAL II and select GUARDIAN locks. The BLE module is a separate procurement decision from the lock body.
• Apple Wallet / Google Wallet — not natively supported on Be-Tech as of May 2026 based on the publicly available English material. This is a clear gap versus Saflok and VingCard.
• Third-party mobile-key partners — Be-Tech does not publish named OpenKey / FLEXIPASS / HID Origo integration pages in the English material. Properties needing third-party mobile-key compatibility should validate before commitment.
• Mobile-only operating models still need a physical card-stack baseline; in budget-hotel markets where Be-Tech dominates, this is also the cost-effective baseline given the price-led positioning.

PMS integration — generic outbound interface plus regional PMS

Be-Tech's PMS-integration story is less standardised than Saflok / SALTO / VingCard. Be-Tech publishes BIS HOTEL as supporting external PMS integration but does not maintain a public certified-partner program for Oracle OHIP or for other major PMS platforms in its English material. In practice, Be-Tech estates integrate via a generic outbound room-key interface; the specifics are negotiated per project.

• Oracle OPERA — integrated via Be-Tech's outbound key interface rather than as a certified partner. Confirm the actual connection method with Be-Tech for any OPERA-on-Be-Tech property.
• Regional Chinese PMS — Be-Tech has stronger published integration with regional Chinese / Asian / Middle Eastern PMS platforms aimed at the budget-hotel segment. Confirm the specific PMS pairing with Be-Tech directly.
• Manual front-desk workflow — many Be-Tech estates run BIS HOTEL as a stand-alone front-desk application without a PMS-integration layer, which is consistent with the budget-hotel target market.
• Cloud PMS pairings — confirm individually; Be-Tech does not publish a marketed cloud-PMS partner list.

Security posture — no public CVE, anti-hacker FLASH RAM safeguard, Crypto-1 caveats

Be-Tech publishes a distinctive anti-hacker safeguard claim and has no public CVE entries in NVD or cve.org as of May 2026. The procurement-narrative on security is favourable on those signals; standard validation still applies because the MIFARE Classic 1K cipher (Crypto-1) used across all Be-Tech hospitality locks is broken industry-wide and independent of any Be-Tech-specific implementation.

Be-Tech's documented safeguard language: "anti-hacker technology does not allow re-programming of FLASH RAM lock memory from the outside escutcheon." This addresses a specific historical attack class — keypad / external-port reprogramming of older hotel locks (most famously demonstrated against Onity HT-series locks in 2012). Be-Tech's claim is that the GUARDIAN series specifically forecloses the equivalent surface on its locks.

Be-Tech also markets its quality and certification credentials prominently: "81 national patents, 50 international certificates", "BHMA, UL fire, CE" approvals where applicable, and a 1-million-cycle endurance rating ("100万次"). These are quality claims rather than security claims; an independent procurement diligence pass on Be-Tech for high-value access zones should still include a Crypto-1 risk assessment regardless of vendor.

Common field failure modes

Field failures on Be-Tech estates follow a predictable pattern. Understanding where the break usually happens shortens the troubleshooting cycle and prevents unnecessary card replacements.

• Wrong mortise variant. A BASE RFID 9004 ANSI shipping to an Australian-mortise installation produces a hardware-mount mismatch rather than a card failure — but the symptom is often presented as "the lock doesn't read the card." Verify mortise variant first.
• MIFARE Classic sector-key mismatch after a BIS HOTEL reinstall. Re-export the site key from BIS HOTEL and re-initialise the encoder before issuing test cards.
• Encoder firmware older than BIS HOTEL build. Encoder enumerates but the issuing software rejects writes; firmware update on the encoder is the fix.
• All-in-One card collision. A loyalty / POS / vending application writing to sectors Be-Tech reserves (rather than the eleven free sectors) breaks the hotel-access flow. Document sector allocation in a card data map before approving an All-in-One programme.
• VISUAL II BLE module not provisioning a Mobile Key. The BLE module may not be installed (verify physically) or the Mobile Key app subscription is not active for the property.
• Power-cycle clears RTC on older BASE locks. Be-Tech's GUARDIAN-flagship locks have better RTC retention; lower-tier BASE locks may need a more conservative power-outage operational policy.

Card material and thickness constraints

Be-Tech reader heads accept standard hotel card stock. Premium materials should be piloted because Be-Tech's antenna tuning is less publicly documented than the major brands.

• Standard ISO/IEC 7810 ID-1 thickness (0.76 mm ± 0.08 mm) is the safe default across BASE, SHADOW, VISUAL and GUARDIAN reader heads.
• Thicker cards (1.0–1.2 mm) — premium PVC, wood-effect, recycled-content cards — may read reliably on GUARDIAN and VISUAL but should be piloted on the specific Be-Tech lock model before any bulk order.
• Bamboo and wood cards with a MIFARE Classic 1K inlay can be specified for Be-Tech, but the lack of published antenna-tolerance specs makes early piloting essential.
• Metal-edge and anti-metal cards are not recommended for Be-Tech; the shielding will detune the antenna and producing intermittent reads.
• Inkjet-printable card stock for in-house printing is widely deployed on budget-hotel Be-Tech estates as a cost-control measure.
• Key fobs — Be-Tech offers a key fob variant compatible with the same MIFARE Classic 1K credential class; common for staff areas.

What to validate before scaling

A Be-Tech pilot should exercise the chip, the lock-series reader head, the encoder firmware, BIS HOTEL workflows and the PMS integration together. Scaling before all five are proven is especially expensive in budget-hotel rollouts where the unit-margin per card is low.

• Test one baseline MIFARE Classic 1K card on the actual Be-Tech series and mortise variant — BASE, SHADOW, VISUAL or GUARDIAN — before approving the card SKU.
• If an All-in-One card programme is in scope, validate that the property's loyalty / POS / vending applications write only to the 11 free sectors that Be-Tech exposes.
• Run a full check-in, extend, re-encode and cancel cycle in BIS HOTEL — and through whichever PMS integration is in scope — to surface connector edge cases. Be-Tech's generic PMS-outbound interface needs particular scrutiny.
• Log the BIS HOTEL version, encoder firmware and lock-series firmware for every tested unit before going to production. The 2015 5.7 manual is the latest dated artefact in the visible English material; newer builds may have undocumented changes.
• Plan a small (100–200 card) first production batch before scaling to the full property order; budget-hotel rollouts amplify the cost of field failures.

FAQ