A machine can accept a card while the buyer still has no clear answer to a more consequential question: which organization is responsible for protecting the account data involved in that payment? A proposal may name a cabinet manufacturer, a reader brand, a software platform and a local processor. Those names describe a supply chain. They do not, on their own, explain the service purchased or the duties retained by the operator.

For a B2B equipment buyer, the useful starting point is a payment-service dossier attached to the exact configuration. It should identify the merchant, the payment provider, the services in use and the people who maintain the evidence after installation. This article explains how to request that dossier and compare three real WEIMI product listings through that lens.

The factual foundation is a PCI Security Standards Council FAQ on merchants outsourcing all payment processing, reviewed on 9 October 2026. It states that outsourcing does not remove a merchant’s responsibility to ensure account data is properly protected by the third party. The workflow below is a procurement recommendation based on that guidance, not an assessment of any particular installation. No WEIMI model or named provider is certified, ranked for security or declared compliant by this article.

PCI SSC says many requirements may not apply directly to a merchant’s environment when payment processing is fully outsourced and the merchant does not store, process or transmit cardholder data. That qualification matters: do not assume it describes your architecture merely because the reader is supplied by a third party.

Confirm validation obligations with the organization managing the merchant’s compliance program, such as its acquirer or payment brand. The FAQ mentions self-assessment questionnaires, but it is not a basis for selecting SAQ A for every vending deployment. The appropriate route requires configuration-specific confirmation.

This comparison separates publicly described retail mechanics from evidence that must be requested for the actual payment service. An unfamiliar answer in the right-hand column is a reason to resolve the configuration, not a verdict that the cabinet is unsuitable.

None of these rows establishes PCI DSS status. A retail feature such as a touchscreen, electronic lock, camera or weight sensor does not answer the service-scope question.

This guide is for operators importing cashless vending equipment, distributors assembling a local payment configuration and corporate buyers bringing several parties into one unattended retail project. It is especially relevant when the hardware seller supplies the machine but a different organization holds the merchant agreement or manages acquiring.

Invite procurement, finance, the payment-program owner and the technical team to the same review. Procurement needs a deliverable it can reference in the purchase order. Finance needs to identify the merchant and the acquiring relationship. Technical staff need to describe the data flow rather than simply name a reader. Operations need a contact who remains available when a terminal, service or site configuration changes.

If an employer buys the equipment while an external operator runs the retail service, clarify which party is the merchant for the proposed arrangement. Ownership of the cabinet is not enough to answer that question. Record the answer in the commercial documents and confirm it with the payment parties. This article cannot decide the roles of parties whose contracts it has not reviewed.

Our evaluation is a review of public manufacturer descriptions followed by questions for procurement. We have not inspected these payment environments, performed a security test or assessed a provider’s compliance. The shortlist is organized by the retail process that a buyer needs to document, not by an independent security score.

Use provider-approved test environments for any demonstration. Ask for redacted example reports or synthetic records rather than real card details. Do not put sensitive payment records into a general inquiry form, product screenshot or shared equipment specification.

1. The legal entity and the service name

“Payments included” is too broad for acceptance. Ask which legal entity offers the service, which agreement the merchant signs and which country configuration is being proposed. Different parties can supply hardware, processing and support. Request a written description of those roles instead of allowing a logo to stand in for the service.

2. Evidence that covers the purchased scope

PCI SSC’s FAQ says the merchant remains responsible for ensuring the provider is compliant for the services offered. Ask the provider what current evidence it can supply, how that evidence maps to the service in your quote and how it should be reviewed under your compliance program. If an attestation is supplied, reconcile entity, scope and assessment information with the proposed service. Do not treat this buyer checklist as a substitute for qualified review.

3. Written acknowledgment of responsibilities

The FAQ refers to written agreements including acknowledgment of provider responsibilities under Requirement 12.8.2. Request that agreement and a readable allocation of shared duties. The allocation should distinguish who performs a task from who checks completion. A promise that the system is secure is not a task allocation.

4. Annual monitoring with an actual owner

The FAQ calls for monitoring provider compliance status at least annually under Requirement 12.8.4. Put an owner and review date in the operating calendar. Decide how the provider supplies updates, how the reviewer records its conclusion and how a missing or changed status is escalated. A dossier filed only at purchase can become stale.

5. The boundary of the cabinet supplier’s work

Ask whether the equipment supplier merely mounts a reader, integrates a payment interface or also provides a payment service. Confirm what remote support can access and which party authorizes changes. These questions clarify the deployment; the public WEIMI product listings do not answer every account-data or service-provider question.

6. Validation instructions from the accepting organization

Ask the acquirer, payment brand or other organization managing the program which validation obligations apply. Retain its written instructions alongside the configuration description. Do not select a questionnaire based solely on an equipment brochure or a generic statement about outsourcing.

The following three genuine products form a procurement shortlist based on public manufacturer listings. “Best” means potentially suitable for the stated retail workflow after configuration review. It does not mean independently tested, PCI-approved or universally compatible with a particular reader or acquirer.

Use this matrix during the configuration meeting. The entries describe questions to resolve, not features we have independently verified. Ask each responding party to give its name, deliverable and decision owner; “the system handles it” leaves the buyer without an accountable handoff.

A documented retail transaction helps the parties understand the architecture, but a successful sale does not prove PCI DSS compliance. Treat operational acceptance and compliance validation as related tasks with separate evidence.

Ask for separate prices for cabinet hardware, payment equipment, integration, connectivity, software and payment services. Add the buyer’s own document review, staff training and ongoing provider monitoring effort to the planning budget. Public product pages do not establish provider fees or the cost of validating a particular merchant environment.

For a simple sensitivity exercise, assume a fictional machine generates $0.85 contribution per completed sale after the costs included in the operator’s own model. Recovering the $420 initial administrative allowance would require $420 ÷ $0.85 = 494.12, rounded up to 495 additional completed sales. Recovering the $210 recurring allowance requires 247.06, rounded up to 248 sales. There is no evidence that this review creates those additional sales; the calculation only translates an assumed cost into a planning unit.

Do not claim a financial return from avoiding a hypothetical breach or assign an unsupported probability to an incident. Compare actual quotes and your own contribution model, then decide whether the proposed arrangement is acceptable. If compliance-program obligations are unresolved, an attractive machine margin does not resolve them.

One operator, one confirmed local provider

Start with the retail format that suits the approved assortment, then document one precise terminal and service configuration. WM22 may suit tested selection-and-delivery paths; an AI fridge may suit browsing and mixed baskets. The better payment choice is the documented arrangement accepted under the merchant’s program, not the cabinet with the most payment logos.

An importer assembling the service after delivery

Resolve the reader and provider interfaces before finalizing the equipment scope. Request the supplier’s integration deliverable, the local provider’s service evidence and the merchant’s validation instructions as separate documents. A promise that a reader can be installed later leaves both compatibility and responsibility questions open.

A fleet spanning several destination markets

Maintain a configuration register by service and market rather than a single generic fleet statement. Record where provider, agreement or terminal arrangements differ. Common cabinet hardware does not prove that every deployment uses the same payment service or has the same validation obligations.

A meal program with multiple support teams

The hot food unit warrants a review that includes payment, access and heating handoffs. Assign who responds to each kind of failure, while keeping food-service controls distinct from account-data responsibilities. Choose the format only after both operating workflows have named owners and evidence.

In an office refreshment project, the equipment buyer may be facilities while the merchant is an external operator. Use the dossier to document that relationship and the provider services before the machine reaches the site. This is a proposed application, not a verified WEIMI customer case.

For a distributor offering a cashless equipment bundle, create a repeatable document request that travels with the quote: configuration identification, provider service description, scope-matched evidence, written responsibilities and accepting-organization instructions. Reuse the request structure, but review the actual answers for each arrangement.

For an operator replacing a reader or moving to a different provider, reopen the service map. A cabinet may remain physically unchanged while the payment arrangement changes. Review the new scope and responsibilities before treating the old acceptance pack as current.

For a corporate meal service, include payment-provider status monitoring in the ongoing ownership calendar alongside the distinct food-service work. Do not place confidential payment material in routine restocking reports. Keep the evidence pack accessible to the people authorized to review it.

Approve a cashless vending purchase only after the parties can describe the actual retail-to-payment arrangement and the merchant understands what it must maintain. Use the public equipment shortlist to decide which retail workflow to investigate, then use the provider evidence pack and compliance-program instructions to settle the payment obligations.

The decisive procurement deliverables are a named service, scope-matched evidence, written acknowledgment of responsibilities, an understood allocation of shared duties and an owner for at-least-annual provider-status monitoring. Keep them tied to the configuration that is installed. A successful tap, a functioning cabinet and an appealing cost model each answer useful questions, but none replaces those deliverables.

Source and boundaries: The PCI SSC outsourcing FAQ supports the responsibility statements above. The three linked WEIMI pages support the product descriptions. The dossier structure, configuration register and review workflow are recommendations. No prices, security test results, customer outcomes, provider certifications or legal compliance conclusions are claimed.