When you offer an employee app alongside your cabinets, the API has to connect a person, a shopping session and a final basket. The operator also needs a record that explains how the purchase was funded and what happened if it was corrected. Door access is only one part of that flow.
Ask an app supplier to walk through one complete purchase on your exact model, including a lost response or a payment refusal. That discussion usually reveals more about the integration than a list of API endpoints.
The questions below are requirements to assess with your technical team, operator and payment provider. Support for each one needs to be established for the proposed installation.
In this guide
Define the model and commercial access first
Start with the cabinet model, firmware, cloud service and API version. Add the operator organisation that owns or manages it, the country of use and the intended payment route. A product family name is too broad to establish compatibility.
Confirm that the manufacturer permits the proposed use of its API, including a separately branded app and access by the intended operator. Ask who grants credentials, which functions they cover and what happens when the operator changes provider. A working internal dashboard is not evidence that the same operations are available to an external app.
Husky’s Intelligent Fridge page, for example, describes its own dashboard, app and APIs. To assess a separate app, request the third-party access terms and documentation for the selected model. The product page does not establish a MoiPass connection.
Identify the user, operator and cabinet separately
The app user, their employer, the cabinet operator and the manufacturer’s API account represent different relationships. Decide which identifier belongs to each party and where the mappings are maintained. Avoid treating an email address or a displayed company name as the transaction key.
For every operation, ask two questions: is the caller authenticated, and may that caller act on this particular cabinet, session or transaction? OWASP’s object-level authorisation guidance explains why possession of an object ID is not sufficient authorisation.
The review should also cover credential expiry, rotation and revocation. When an employee loses access, how quickly do new sessions stop? When an operator is removed, can an old credential still read its transactions? Privileged manufacturer credentials should remain under the control of the trusted integration service rather than being distributed as shared app credentials.
These are questions for the full system. The cabinet API may enforce one boundary while the app enforces another; the contract should say which party owns each check.
Follow a session through to the final basket
A useful reference flow is:
- Identify the cabinet and check that the user may start a purchase there.
- Apply the agreed budget and payment checks before requesting access.
- Create a session with a reference that can be traced across systems.
- Request access and distinguish an accepted command from confirmed physical access.
- Receive or retrieve the final basket after the cabinet finishes identifying the purchase.
- Record the agreed funding allocation and the payment outcome, then make the receipt or purchase record available.
The API does not need to use these exact steps or names. It does need enough information to distinguish the states that matter. Ask what proves that a basket is final, whether it can later be corrected, and how an empty basket differs from a failed purchase.
Selfly’s documentation makes a useful distinction. Its application check-in example includes a user ID, cabinet code and transaction reference. The generic transaction-reporting webhook is described as carrying product information without user information. A separate cloud-payment flow covers sessions and capture/reversal interactions. Check which flow is being proposed before deciding how the app will identify the buyer.
For your model, trace the user-to-session-to-basket link explicitly. If one event lacks the employee reference, establish how it can be joined to an authorised session without guessing from timestamps. A product inventory change alone is not an employee purchase record.
Separate the basket, employer contribution and payment
The cabinet platform should identify what was purchased. The agreed budget service determines which part the employer may fund. The payment arrangement determines how any personal amount is authorised, collected or returned. One supplier may provide several of these functions, but they remain separate responsibilities.
Ask for stable product identifiers, quantities, prices, currency and the meaning of the amounts supplied. Are prices inclusive of tax? Which price applies if the catalogue changes during a session? Can an item correction be linked to the original basket? Require an explicit money representation and precision rule rather than inferring units from a sample value.
Budget checks need their own decisions. If the final basket exceeds the available employer contribution, does the agreed personal payment route cover the remainder? What happens if that payment fails after goods have been taken? Define the rule before the pilot. It cannot be inferred from a manufacturer’s “payments supported” statement.
An empty-basket reversal, a cancelled authorisation and a refund after a completed purchase are different events. Ask which system initiates each one and how its outcome is recorded. For a partial refund, the proposed record should preserve the relationship to the original items and funding sources. Confirm this behaviour in the proposed implementation before including it in your offer.
Treat retries and missing events as part of the design
For each API call that changes state, ask what a safe retry means. If a door-access request times out, did the cabinet reject it or did the acknowledgement disappear? The answer should come from a session-status lookup or another documented recovery mechanism. Sending another command without knowing the state can make the problem harder to resolve.
For incoming events, require a way to authenticate the sender, identify duplicates and recover missing information. Stripe’s webhook documentation gives a concrete payment-platform example: delivery may be duplicated and event order is not guaranteed. That behaviour should not be assumed to be Selfly’s contract; it is a useful prompt to request the cabinet supplier’s actual delivery guarantees.
Agree how the integration prevents a repeated notification from producing a second budget deduction or payment action. Also distinguish an HTTP acknowledgement from completion of the business operation. A webhook accepted by the receiver does not, on its own, prove that the employee was correctly charged.
When the result remains uncertain, the operating process needs a visible unresolved state, an owner and a recovery route. “No error reported” should not be the condition for closing a financial record.
Use a questionnaire that separates documentation from tests
Complete this for one model and set of versions. Record documented support with a reference and tested behaviour with a result and date. Keep those two columns separate: documentation alone is not a successful device test.
The unknown entries are blank starting values for your assessment, not findings about a particular manufacturer.
| Capability to assess | Question for the manufacturer or responsible provider | Documentation / reference | Model test / date |
|---|---|---|---|
| Model and permission | Which model, firmware, cloud/API version and third-party rights are covered? | unknown | unknown |
| Organisation boundaries | How is access restricted to the authorised operator and cabinets? | unknown | unknown |
| User mapping and revocation | Which identifiers link users to sessions, and how is new access revoked? | unknown | unknown |
| Catalogue and money | Which IDs, price semantics, currency units and precision rules are supplied? | unknown | unknown |
| Access and session state | Can a caller distinguish command acceptance, access and session completion? | unknown | unknown |
| Final basket | Which event or lookup gives the authoritative items and amount? | unknown | unknown |
| Corrections | Can a revised basket or item correction be tied to its original transaction? | unknown | unknown |
| Payment boundary | Which party authorises, captures, reverses and reports the outcome? | unknown | unknown |
| Employer and personal funding | Where is allocation decided, enforced and recorded? | unknown | unknown |
| Event security and delivery | How are senders authenticated, duplicates identified and retries handled? | unknown | unknown |
| Recovery | Can sessions and transactions be retrieved after a timeout or lost event? | unknown | unknown |
| Refunds | How are full/partial refunds and funding-source corrections represented? | unknown | unknown |
| Availability and limits | What do offline status, rate limits, maintenance and support escalation mean? | unknown | unknown |
| Export and change control | Can records be exported, and how are API changes and termination handled? | unknown | unknown |
If a responsibility sits outside the cabinet API, name the system and party that will provide it. Mark a confirmed unsupported function explicitly once the supplier answers. Do not turn a blank into “supported” because an adjacent feature exists.
Agree who handles the purchase when something goes wrong
The white-label contract should explain more than logos and colours. It should identify the brand owner, operator onboarding process, distribution arrangements for the app, support route and access to operating records. Define these independently of a claim that an app is already published in an app store.
Name the party that investigates an incorrect basket, changes employee eligibility, acts on a payment dispute and maintains the integration. Agree who can read, correct and export the records. A support request should reach the team able to resolve it without the employee having to identify which system failed.
For the procurement comparison, use the build-or-buy guide. For operators, these answers shape the service they can offer an employer. The operator solution is the next discussion if the model and app need to work across several corporate customers.
Make the pilot prove recovery as well as a purchase
Choose one named cabinet model, an authorised test environment or device, and a limited group. Record the versions, sample data, expected outcomes and the people who will accept the results. Use synthetic identifiers and remove credentials and personal data from the review material.
Alongside a successful purchase, exercise an empty basket, a duplicate event, a lost response after an access request and a delayed final basket. Where the proposed flow includes them, test insufficient employer funding, personal payment failure, a partial refund and access revocation. Finish with a sample period report that explains the final purchases and their corrections. A test not performed should remain untested.
MoiPass focuses on employee shopping budgets and an app that manufacturers or operators can offer under their own brand. Selfly is the existing connection referenced in the current product scope. Husky connections are assessed model by model; another internet-connected cabinet is a new compatibility assessment. Country-specific benefits and payment support need separate evidence.
See the manufacturer solution and the current integration scope. Share your cabinet model and API scope, and we can identify what is documented, what needs a test and what remains unknown before defining a pilot.
Public documentation describes the published interface. It does not prove that an integration has been completed for a particular model.