The First Question Is Not “Which Card Dispenser?”

When somebody asks us for a hotel key card dispenser, it is tempting to start with a model number. In practice, that is usually too early.

The same request can describe three very different projects:

a kiosk manufacturer needs an embedded module for a cabinet it is already building;
a hotel wants a compact desktop unit at reception or beside an existing tablet;
a software company needs a complete self-check-in kiosk with the screen, controller and peripherals already integrated.

All three projects may issue the same room card, but their mechanical design, software responsibilities and delivery scope are not the same. If the equipment format is not confirmed first, both sides can spend days discussing card capacity and RFID frequency while missing the real integration question.

Our standard starting point is therefore simple:

Do you need an embedded card dispenser, a desktop key-card issuing unit, or a complete hotel self-check-in kiosk?

The answer determines what should be supplied, what the customer must integrate and which technical questions need to follow.

Short Answer: Choose by Project Ownership

Choose an embedded module when the customer or kiosk manufacturer owns the cabinet design, industrial PC and application integration.

Choose a desktop unit when the hotel or integrator already has the check-in application and wants a finished card-handling device that can sit on a counter or inside a small reception station.

Choose a complete self-check-in kiosk when the project needs one coordinated hardware package, including the display, controller, card issuing mechanism and selected peripherals.

The table below gives a quick comparison.

Format	Best fit	Customer normally provides	Main integration work
Embedded card module	Kiosk manufacturers and experienced integrators	Cabinet, host PC, application and final wiring	Mechanical mounting, card-slot alignment and host control
Desktop key-card unit	PMS vendors, hotels and counter-service projects	Check-in application, lock-system access and usually the encoder	Application-to-device control and counter deployment
Complete self-check-in kiosk	Hotels, operators and solution providers needing a finished hardware platform	PMS/API access, local payment choice and project-specific credentials	End-to-end application, PMS, payment and lock-system coordination

This is a project-selection guide rather than a universal configuration list. The final hardware depends on the hotel workflow, local ID requirements, payment environment and door-lock platform.

Option 1: Embedded Card Dispensing and Recycling Module

An embedded module is the right starting point when the kiosk enclosure already exists or will be designed by the customer.

The SNR-K750L is built for this type of integration. It handles the physical card workflow: storing cards, moving a card into the transport path, holding it at a defined position, dispensing it to the guest, accepting returned cards and circulating reusable cards where the project requires it.

For hotel projects, the important point is that card movement and room-key encoding are separate jobs. The K750L moves and positions the card. The hotel’s approved lock-system encoder writes the room credential.

Why the removable encoder mounting plate matters

Above the K750L card path is a removable, slotted plastic mounting plate. A compact RFID encoder supplied or approved by the hotel’s door-lock provider can be fixed to this plate. The position can be adjusted during integration so the encoder antenna sits close enough to the card at the writing station.

During operation, the module moves a card under the encoder and holds it in place. After the kiosk application receives a successful encoding result, it sends the command to dispense the completed room key.

This arrangement is useful because hotels do not all use the same credential structure. Two systems may both use a 13.56 MHz MIFARE card and still have different keys, sectors, applications, security settings and issuance software. Using the hotel’s original or approved encoder avoids treating radio frequency as proof of system compatibility.

When an embedded module is the best choice

It is normally the best fit when:

the customer manufactures the kiosk enclosure;
an industrial PC or Android controller has already been selected;
the project team can develop against a serial communication protocol;
the hotel application controls the full sequence;
the designer needs freedom over the card slot, service access and internal layout;
the project may require card return, collection or reuse.

What the kiosk designer must allow for

An embedded product gives the designer flexibility, but it also leaves several decisions with the integrator:

Provide a rigid mounting structure and align the guest card slot with the transport path.
Leave access for loading cards, clearing a jam and servicing belts or rollers.
Confirm the card-box capacity required for the expected operating period.
Reserve space for the selected lock encoder, its cable and any controller or power supply.
Keep metalwork away from the encoder antenna where it could affect reading or writing.
Define how the application responds to an empty hopper, failed encoding, uncollected card or returned card.

The 3D drawing should be placed into the kiosk design early. It is much easier to adjust a card-slot opening in CAD than after sheet metal has been produced.

Option 2: Desktop Hotel Key Card Issuing Unit

A desktop unit suits projects that do not need a full kiosk cabinet. It can be placed on a hotel counter, at a compact self-service station or beside an existing touchscreen.

The SNR-CD760 uses an SNR-K750L card-handling mechanism inside a finished desktop enclosure. It provides the same core benefit: automated card movement with space for a compact hotel lock encoder. The main difference is project scope. The enclosure, internal alignment and basic assembly are already handled, so the customer does not need to design a card dispenser into its own cabinet.

A desktop unit is not always “plug and play”

The hardware arrives as a finished device, but the software workflow still needs to be defined. Somebody must tell the unit when to move a card, when to stop at the encoding position, when encoding has succeeded and when the card may be dispensed.

Before quoting a desktop configuration, we ask one question that changes the control architecture:

Does your hotel check-in application run on Windows or Android?

If the customer application runs on Windows

The Windows application can normally use the supplied protocol, SDK or middleware to control the CD760 card movement directly. The hotel lock encoder is also commonly connected to the same Windows environment through the door-lock vendor’s application or interface.

A typical sequence is:

The application confirms the reservation and guest details.
It requests a card from the CD760.
The CD760 moves the card to the writing position.
The application or lock-system software calls the hotel encoder.
After a successful response, the application commands the CD760 to dispense the card.

In this architecture, a separate Windows mainboard inside the desktop unit may not be required because the customer’s Windows computer already acts as the controller.

If the customer application runs on Android

The desktop unit can be supplied with an internal Windows mainboard. The Android host and the CD760’s Windows controller are placed on the same network.

The Android application sends a defined request to the Windows-side service. That service controls the card transport and coordinates with the hotel encoder. It then returns the transaction result to the Android application.

This creates a clear division:

the Android system runs the guest-facing check-in application;
the Windows controller handles the device sequence and Windows-dependent encoder software;
both systems communicate over the local network using the agreed interface.

This is especially relevant when the door-lock vendor’s encoder software or SDK is Windows-based. It prevents the project from assuming that an Android app can control a Windows-only encoder directly.

The interface between the Android application and the Windows service must still be agreed during development. The internal Windows board is not a substitute for software integration; it provides the environment in which that integration can run.

When a desktop unit is the better fit

Choose the desktop format when:

there is no need to manufacture a full kiosk enclosure;
the hotel wants automated issuing at reception;
the PMS company already has a guest-facing application;
a tablet or existing terminal will be used as the user interface;
the project needs a faster hardware pilot with less mechanical work;
the customer wants optional Windows control hardware in the same enclosure.

For a pilot, the desktop format can also help the software team test the card workflow before committing to a floor-standing kiosk design.

Option 3: Complete Hotel Self-Check-in Kiosk

A complete kiosk combines the card-issuing mechanism with the main user-facing hardware. Depending on the project, that can include a touchscreen, industrial PC or Android controller, QR scanner, receipt printer, camera, payment terminal and passport or ID scanner.

This format is appropriate when the customer wants a coordinated hardware platform rather than a component to install in its own enclosure.

It does not mean every peripheral should be selected by the kiosk manufacturer. Some devices are country-specific, acquirer-specific or tied to an existing hotel system. The project still needs a clear boundary between standard kiosk hardware and locally selected devices.

Typical guest workflow

A common hotel self-check-in flow looks like this:

The guest retrieves the booking using a confirmation number, name or QR code.
The application verifies the reservation with the PMS.
The guest scans an ID or passport if required by the hotel or local regulation.
Contact details, address information or consent are confirmed where necessary.
The guest selects optional services such as breakfast or parking.
The payment terminal authorises the required room and incidental amount.
The PMS and lock-management system provide the information needed to issue the credential.
The encoder writes the room key and returns a success result.
The card dispenser releases the card and the kiosk displays the room information.

The hardware configuration should follow this workflow. It should not be assembled from a generic list of peripherals before the software process is understood.

What to confirm for a complete kiosk

For the controller, confirm:

Windows or Android operating system;
CPU platform and generation;
RAM and SSD capacity;
required communication ports;
remote maintenance and network requirements.

For guest identification, confirm:

national ID, passport or both;
target countries and document types;
scanner model, dimensions and 3D drawing;
the SDK and operating-system support;
whether the scanner will be supplied locally.

For payment, confirm:

payment terminal brand and model;
acquiring bank or payment service provider;
unattended certification requirements;
mounting method and PIN-pad accessibility;
whether the device is supplied by the customer or local acquirer.

For room-key issuance, confirm:

hotel door-lock brand and system;
exact encoder model;
room-card technology and thickness;
encoder SDK, service or vendor application;
card quantity and whether returned cards will be reused.

ID Scanners: Let the Project Location Drive the Selection

ID documents and reader requirements vary by country. A scanner suitable for one market may not support another market’s national ID card, passport workflow or regulatory process.

For this reason, the hotel or local system integrator normally selects the ID scanner. Once the model is known, the kiosk manufacturer can prepare the correct opening, mounting bracket, cable route and internal space.

The customer should provide at least the model, dimensions and preferably a 3D drawing. If the customer sends the physical scanner before production, it can be installed and checked at the factory.

This approach is more reliable than adding an unspecified “passport scanner” to the quotation and discovering later that the device does not support the intended documents or software environment.

Hotel Key Card Encoders: Start with the Existing Lock Brand

The correct question is not simply “Do you need an RFID encoder?” It is:

Which door-lock brand and system does the hotel currently use?

The answer identifies the encoder family and the lock-management software that must take part in the transaction. Hotels using Vingcard, dormakaba/Saflok, SALTO, Onity, MIWA or another platform should confirm the compact encoder recommended for their exact system and credential generation.

Ask the door-lock provider for:

the exact encoder model and part number;
product dimensions or a 3D drawing;
antenna position and recommended card distance;
USB, serial or network requirements;
power requirements;
supported operating systems and SDK or service details.

The kiosk team can then design the mounting position and validate the card-to-antenna alignment. If the customer sends the encoder to the factory, it can also be installed before shipment.

Do not approve compatibility only because the card says MIFARE, DESFire or 13.56 MHz. Those terms describe part of the card technology, not the complete hotel credential process.

Related guide: Learn more about how a hotel door lock encoder works with a self check-in kiosk.

PMS, FIAS and the Door-Lock Interface Are Different Layers

Hospitality projects often use the word “interface” without identifying which systems are actually communicating.

A PMS interface, including a FIAS-based connection where applicable, may exchange reservation, guest, room and status information. The door-lock platform creates the credential accepted by the lock. The card dispenser moves the physical card. These functions may be coordinated by the kiosk application, but they are not interchangeable.

For example, receiving a room number from the PMS does not by itself encode a valid key. The application still needs an approved path to the lock system and must wait for a reliable success or failure result before releasing the card.

A useful project responsibility map is:

Layer	Main responsibility	Typical owner
PMS	Reservation, guest, room assignment and stay data	Hotel or PMS provider
Kiosk application	Guest workflow and transaction coordination	Software provider or integrator
Lock-management system	Room-access credential generation	Door-lock vendor or approved partner
RFID encoder	Writing the credential to the card	Door-lock system
Card dispenser	Card storage, movement, positioning, dispensing and return handling	Kiosk hardware platform
Payment terminal	Cardholder authorisation and payment result	Acquirer or payment provider
ID scanner	Document capture and data extraction	Local device provider or integrator

Writing down this ownership early prevents one supplier from being assumed to provide access to another vendor’s closed system.

A Practical Selection Method

The following sequence works well during the first project discussion.

Step 1: Confirm the physical format

Ask whether the customer needs an embedded module, a desktop unit or a complete kiosk. Do not quote all three as though they are minor variations of the same product.

Step 2: Confirm where the application runs

Ask whether the application runs on Windows or Android and on which computer. This is especially important for a desktop unit and for lock encoders whose vendor software expects Windows.

Step 3: Confirm the hotel’s existing systems

Request the PMS name, door-lock brand, lock-system version and encoder model. If the project will serve multiple hotels, ask whether those hotels use one lock platform or several.

Step 4: Confirm the card workflow

Clarify whether the unit only dispenses new cards or must also accept, collect and recycle returned cards. Confirm card dimensions, thickness, material and credential type.

Step 5: Confirm country-specific peripherals

Identify who will supply the ID scanner and payment terminal. Obtain mechanical drawings before finalising the kiosk enclosure.

Step 6: Draw the control sequence

Define which application sends each command and what response allows the next action. Include timeouts, retries and recovery paths, not only the successful transaction.

Step 7: Test with the real devices

Use the actual room cards, encoder model, lock software and intended controller. A generic RFID demonstration is useful for testing card movement, but it does not prove hotel-system compatibility.

What Information Should Be Sent with an Inquiry?

A useful hotel key-card hardware inquiry should include:

required format: embedded, desktop or complete kiosk;
quantity for sample testing and expected project quantity;
application operating system: Windows or Android;
PMS brand and integration method;
hotel door-lock brand and exact encoder model;
card type, dimensions and thickness;
issue-only or issue-and-return workflow;
required card-box capacity;
ID document types and selected scanner model;
payment terminal model, if a complete kiosk is required;
controller specification for a complete kiosk;
target installation country and certification requirements;
desired delivery schedule.

If some information is not yet available, the two most important details are the hardware format and the hotel door-lock brand. Those answers allow the discussion to move in the right direction.

Common Selection Mistakes

Choosing by RFID frequency alone

A 13.56 MHz label does not confirm access to the hotel’s credential keys or encoding method. Confirm the lock-system-approved encoder.

Assuming a desktop enclosure removes software work

The unit may be mechanically complete, but the application still needs to coordinate card movement and encoding.

Adding an internal Windows board without defining its role

The Windows board should host a defined device-control service or encoder integration. It should not be added simply because the main application runs on Android.

Ordering a full kiosk before confirming local peripherals

Payment terminals and ID scanners are often selected locally. Their exact dimensions and mounting requirements should be known before enclosure production.

Releasing the card without an encoding result

The card should remain under control until the lock system confirms a successful write. A timeout or failed write should trigger a retry, rejection or operator path rather than dispensing an uncertain key.

Treating every hotel rollout as one configuration

A hotel group may use several PMS versions, lock brands and local payment providers. A standard kiosk enclosure can still be used, but the encoder bracket, software connector or peripheral kit may need to vary by property.

Recommended Pilot and Acceptance Test

Before a batch order, build one representative sample using the intended configuration.

Test at least the following:

repeated dispensing from a full, half-full and nearly empty hopper;
positioning under the actual encoder;
successful room-key encoding and lock opening;
rejected, damaged and out-of-tolerance cards;
encoding timeout and retry handling;
network interruption between Android and Windows controllers, if used;
PMS or lock-service interruption;
card not collected by the guest;
card return, collection and recycling where enabled;
restart recovery after power loss;
operator access for loading and maintenance;
full workflow with the selected ID scanner and payment terminal.

The acceptance target should be a stable end-to-end transaction, not merely successful movement of a blank card.

Final Recommendation

The equipment format should follow the party that owns the final integration.

If the customer is building the enclosure and already has a controller, the SNR-K750L embedded module gives the greatest design freedom. If the customer has an application but does not want to design card-handling mechanics, the SNR-CD760 desktop format is more direct and can be configured with or without an internal Windows board. If the project needs a coordinated touchscreen terminal and several peripherals, start with a complete hotel self-check-in kiosk.

Whichever format is selected, confirm the hotel’s current door-lock brand before finalising the encoder. Use the compact encoder recommended by that lock provider, then confirm its dimensions and interface. The K750L can move and hold the card at the encoding position while the hotel encoder writes the room-key data.

For the ID scanner, let the hotel or local integrator select a model that supports the intended documents and country. We can prepare the mounting position from its dimensions or 3D drawing. If the customer sends the ID scanner and hotel key card encoder to us, we can install them before shipment and provide installation drawings or video guidance for future units.

This keeps the project practical: each system performs the job it is designed for, and compatibility is verified before the hardware reaches the hotel.

Frequently Asked Questions

What is the difference between an embedded hotel card dispenser and a desktop unit?

An embedded dispenser is a mechanism installed inside a kiosk designed by the customer. A desktop unit adds a finished enclosure and can be placed on a counter or beside an existing terminal. Both still require software coordination with the hotel lock encoder.

When should we choose a complete hotel self-check-in kiosk?

Choose a complete kiosk when the project needs the display, controller, card-handling hardware and selected peripherals in one coordinated platform, and the customer does not intend to build the enclosure itself.

Does the SNR-CD760 include a computer?

It can be configured with or without an internal Windows mainboard. The correct version depends on where the customer’s application runs and how the lock encoder will be controlled.

Our application runs on Android. Can it control the desktop card unit?

Yes, but the control architecture must be defined. One approach is to use a CD760 configuration with an internal Windows board. The Android application and Windows controller communicate over the same network, while the Windows service coordinates the card mechanism and encoder.

If our application runs on Windows, do we need the internal Windows mainboard?

Not necessarily. The customer’s Windows host may control the card unit and encoder directly using the agreed protocol, SDK or middleware. The final decision depends on the application architecture and available interfaces.

Can the built-in RFID reader write our hotel room keys?

It may communicate with certain standard card families, but that does not establish compatibility with a hotel lock system. For room-key issuance, use the hotel lock vendor’s original or approved compact encoder whenever possible.

How do we select the correct hotel key card encoder?

First confirm the hotel’s current door-lock brand, system and credential generation. Then ask the lock provider for the recommended compact encoder, exact model, dimensions, interface and software requirements.

Can the encoder be installed on the SNR-K750L?

The K750L provides a removable plastic mounting plate above the card path for a compact third-party encoder. Mechanical fit and card-to-antenna distance must be checked using the exact encoder model.

Who should supply the ID scanner?

The hotel or local integrator normally selects it because identity documents and compliance requirements vary by country. We can prepare the kiosk mounting position from the scanner’s model, dimensions or 3D drawing.

Can you install the ID scanner and hotel encoder before shipment?

Yes. If the customer sends the selected devices to us, we can install them during assembly and check the mechanical fit, cable routing and card position before shipment.

Does FIAS encode the room card?

No. FIAS is generally associated with PMS interface messaging. The lock-management system and its approved encoder create and write the room-access credential. The kiosk application coordinates the two workflows.

What should we send before requesting a quotation?

At minimum, tell us whether you need an embedded module, desktop unit or complete kiosk, where your application runs, and which door-lock brand the hotel uses. Encoder details, PMS information, card samples and peripheral drawings will make the quotation and integration plan more accurate.

Which hotel card-issuing format fits your project?

Tell us whether you need an embedded module, desktop unit or complete kiosk. Please also share your application operating system and the hotel’s current door-lock brand. We can then recommend the correct hardware scope and confirm what is needed for the compact encoder, ID scanner and controller integration.

Discuss Your Hotel Kiosk Project

View Card Dispensers