WEIMI INSIGHTS / SMART FRIDGES • SESSION DESIGN
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.
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
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
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
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
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
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
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.
Contains: a defined door, stock map and equipment state.
Question: can it be serviced or disabled independently?
Contains: the allowed cabinet access and item events.
Question: when does it begin and end?
Contains: the supported authorisation and settlement flow.
Question: how does it reconcile with the session?
PRACTICAL ANSWERS
Do not assume that. The supported controller, software, payment arrangement and capacity limits need confirmation.
No. The visible interface and the underlying session design are separate questions.
That depends on the architecture and fault. Ask for configuration-specific behaviour at both cabinet and shared-system levels.
YOUR NEXT STEP
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 →