loading


Product

One Card Reader for Multiple Smart Fridges: Define the Session and Cabinet Rules

A system-design brief for shared payment terminals with separate doors, stock records and product recognition.

WEIMI INSIGHTS   /   SMART FRIDGES • SESSION DESIGN

Sharing a reader is a transaction design question, not just a wiring question.

A system-design brief for shared payment terminals with separate doors, stock records and product recognition.

SELECT

Identify the cabinet the customer intends to access.

ATTRIBUTE

Keep items and events connected to the right session.

RECOVER

Define what happens when one cabinet cannot complete.

THE DECISION IN ONE LINE

Do not assume a payment terminal can serve several independent fridges without an explicitly supported controller and transaction design. Ask for the full session workflow.

01   /   BUYER NOTES

Choose the intended customer journey

State whether a customer selects one cabinet before authorisation or can shop across several cabinets within one session. These are different system behaviours. The intended journey should be clear before discussing terminal count.

For a one-cabinet session, describe how the selected door is identified and opened. For a multi-cabinet session, describe the allowed order of access and how the customer knows when the session is complete. Do not leave those steps implicit.

Ask which journey the proposed system actually supports. A shared screen or a group of cabinets in one location does not establish a shared payment session.

02   /   BUYER NOTES

Keep each cabinet’s identity and stock separate

Assign a clear cabinet identifier that matches physical labels, software records and support information. Each door, sensing arrangement and stock map needs an unambiguous association with that cabinet.

Ask how the system attributes removed items to the correct cabinet and session. The answer should describe the supported architecture at a useful level without requiring access to unrelated customer data or internal credentials.

Confirm how staff refill or service one cabinet while others remain in normal use. A shared payment point should not cause a maintenance action to be confused with a customer purchase. The supported service mode needs to be demonstrated.

03   /   BUYER NOTES

Define authorisation and final amount responsibilities

Discuss the payment sequence with the responsible provider and integrator. Identify when authorisation occurs, how the final purchase amount is determined and which system submits the appropriate result. Do not assume the reader’s ordinary single-cabinet behaviour extends automatically.

If pre-authorisation is used, explain it accurately in customer-facing information based on the actual provider arrangement. Avoid inventing a universal hold amount or release time. Those details can depend on the service and the customer’s bank.

Keep product totals and payment totals reconcilable through supported transaction references. A combined sale still needs enough detail for stock and customer support without collecting unnecessary card information.

04   /   BUYER NOTES

Consider overlapping customers and open doors

Ask what happens if another person approaches the shared reader while a session is active. The interface should communicate the supported next step and prevent ambiguity about which customer controls which cabinet. Do not assume concurrent sessions are available.

Define how a door left open affects the session and other cabinets. Request the actual timeout, notification or operator process where supported. A proposed alarm or automatic action should remain unconfirmed until the supplier has described and demonstrated it.

Use controlled scenarios in the acceptance plan. The goal is to understand session boundaries and customer messages, not to bypass locks or probe security weaknesses.

05   /   BUYER NOTES

Plan faults at the cabinet and shared-system levels

A single cabinet may have a door, cooling or recognition issue while the payment point remains available. Ask whether the affected cabinet can be taken out of service and what effect that has on the others.

Also assess shared dependencies. If the reader, controller or connection serving the group is unavailable, several cabinets may lose a function at once. Confirm the supported behaviour and the operator response rather than assuming complete independence.

Define customer support for a partially completed multi-cabinet purchase. Staff need to identify which access and item events occurred before deciding the appropriate resolution under the actual system and policy.

06   /   BUYER NOTES

Compare savings with operating complexity

A shared terminal may reduce some hardware, but it can introduce coordination requirements and a shared point of interruption. Compare the total configuration, integration work and service arrangement with separate supported terminals.

Use the same intended product range and customer scenarios in the comparison. Measure the complete purchase experience and review records from the test. A successful card tap followed by one door opening is not evidence that every multi-cabinet scenario works.

Approve the exact configuration and retain the session diagram with the project documentation. Future cabinet additions should be reviewed against the supported limits and workflow, rather than treated as a simple physical expansion.

Three system boundaries to define

Cabinet boundary

Contains: a defined door, stock map and equipment state.

Question: can it be serviced or disabled independently?

Customer session

Contains: the allowed cabinet access and item events.

Question: when does it begin and end?

Payment transaction

Contains: the supported authorisation and settlement flow.

Question: how does it reconcile with the session?

PRACTICAL ANSWERS

Questions worth asking before you order

Can one card reader operate any number of fridges?

Do not assume that. The supported controller, software, payment arrangement and capacity limits need confirmation.

Does one screen mean one shared payment session?

No. The visible interface and the underlying session design are separate questions.

Will a fault in one fridge leave the others working?

That depends on the architecture and fault. Ask for configuration-specific behaviour at both cabinet and shared-system levels.

YOUR NEXT STEP

Describe the complete multi-cabinet journey

Tell WEIMI how many cabinets you plan and whether customers should shop in one or several per session. Request a supported transaction diagram and a joint payment-integration review.

Explore equipment →Discuss your requirements →

prev
20 or 40 Cake Lockers? Size the Bank Around Occupancy and Collection Windows
Connecting Smart Fridge Alerts to a Site Alarm: Define the Event Before the Output
next
recommended for you
Get in touch with us
Customer service
detect