Reverse Vending Machine OEM Specification Checklist

Reverse vending machine OEM specification: nine lines to lock before you sign

The specification lines that decide RVM acceptance are container recognition with a written pass/fail test, a refund payout module matched to deposit value and duty cycle, and a signed document pack — IP/EMC/safety reports plus a BOM with named sub-assemblies. Price ranks fourth.

Everything else on a datasheet is negotiable in importance; those three are not, because they are the lines that determine whether your machine clears scheme acceptance at the return point and whether a coin jam in month seven is a service call or a dead asset in a supermarket back-of-house.

One limitation, stated up front because it changes how you read this checklist: no public dataset verifies recognition rate, MTBF, throughput or dispense-cycle reliability for any RVM supplier. Those numbers are not published by scheme operators, not standardised, and not auditable from a brochure. They exist only in a factory acceptance test you witness, on a container library you supply. Treat every percentage a sales team quotes as a claim awaiting a test protocol — and if a supplier resists writing one, that is your shortlist answer.

Context matters for where you deploy: supermarkets and hypermarkets represent the largest end-use segment of the RVM market at 49.6% (HTF Market Intelligence market report; no publication date supplied in the source excerpt). High-footfall retail return points generate the acceptance pressure — queue tolerance, bin-fill frequency, payout uptime — that your specification should be written against.

Nine specification lines and the document that makes each one falsifiable

Item 1 — Recognition architecture: name the authorisation path, not the technology

Two architectures are routinely sold under the same word, and they carry different acceptance risk.

• Barcode-scan-to-refund authorisation. The machine reads the container barcode, checks it against a container database, and only then authorises the refund. Slovakia's DRS, operational since 2022 with TOMRA-built machines, works this way: it accepts plastic and metal beverage containers between 0.1 and 3 litres and scans barcodes to confirm container type before authorising a refund — 3,269 collection points by end-2023, roughly three-quarters equipped with RVMs, with a 92% second-year return rate reported ( Sweet Lightning, 29 July 2026 ; a secondary publisher summary, not a scheme-operator primary document — verify against the national scheme's own technical annex).
• Shape / material matching. The machine classifies by geometry, weight or material sensing, typically as a pre-filter or as the primary path. It handles unlabelled and damaged containers differently, and its failure mode is a false accept rather than a rejected barcode.

The decision impact: barcode-led authorisation ties your machine to a container database that needs updating every time a private-label SKU, a promotional pack or a new format enters the market. Ask who owns that database, how updates ship (local file, cloud sync, USB on site) and — critically — what the machine does with a valid container whose barcode is not yet in the database. Whichever answer you get, write it into the acceptance criteria.

Document to demand: a one-page architecture note showing the full decision tree from container inserted to refund authorised, including the offline branch.

Item 2 — Recognition acceptance test: measure false accepts and false rejects on your own library

This is where shortlists are won and lost, and where the competing pages on this topic stop. Nobody can give you a trustworthy recognition rate, so specify the test instead of the number.

1. Build the container library from your target market. Include crushed containers, wet containers, label-damaged and torn-label variants, private-label duplicates of national brands, containers at the small and large ends of the accepted size range, and deliberately out-of-scope items.
2. Define the two failure metrics separately. False reject = eligible container refused (consumer annoyance, queue friction). False accept = ineligible container refunded (direct financial leakage and scheme non-compliance). They are not symmetrical, and a supplier that reports one blended "accuracy" figure is hiding the one you care about.
3. Fix the sample size and repeat count in the protocol before the test , and record every transaction in a log you take away with you.
4. Test the rejection path explicitly. In the Slovak scheme, dairy, syrup and spirit containers fall outside scope. Ask how the machine rejects an out-of-scope container and what the consumer sees on screen — an error message, a silent return, or a refund.

Regulatory timing to press suppliers on: the UK's Deposit Management Organisation has reportedly published the hardware requirements for RVMs, while software and programming requirements remain in development with release planned for summer 2026 ( Exchange for Change ). Ask each candidate which specification revision and firmware baseline their hardware is currently built against, and whether a firmware change to meet the software requirements will be chargeable. If you are deploying into an EU market, PPWR-driven deposit-return obligations are also reshaping national scheme timelines — confirm the applicable national technical specification directly with the scheme administrator rather than relying on any supplier summary.

Item 3 — Refund payout module: match the module to deposit value and duty cycle

Payout is a cash-handling problem dressed as a kiosk feature. Decide the payout mix before you choose hardware:

• Coin only — lowest module cost, highest dispense-cycle count per deposit, and hopper exhaustion is a real risk in high-deposit markets.
• Note payout or note recycling — fewer cycles, but note path length and jam access become the dominant service metric.
• Coin + note recycling — the configuration to interrogate hardest, because recycled notes and coins arrive from consumers and must be validated again before being paid out.
• Cashless voucher / QR / account credit — removes the cash module, moves the risk to scheme clearing and settlement, and makes your offline behaviour design the critical line instead.

Interrogate payout capacity as a duty cycle , not a capacity figure: deposits per hour, dispense cycles per hopper fill, note-acceptor path length, and where a jam is cleared from. Ask for the payout module's own service data — dispense failures per 10,000 cycles and the module and stacker part numbers. If the supplier cannot name the payout module's sub-supplier, treat it as a shortlist fail. You are buying a serviceable assembly, and an unnamed module is an unserviceable one.

If card or account credit is in scope, require a written PCI DSS scope statement confirming whether card data ever touches the kiosk PC or stays inside a certified payment terminal. A verbal "we're compliant" is not a document.

Finally, specify the audit trail: what the consumer receives, what the scheme operator receives, and how a disputed refund is reconstructed three weeks later.

Item 4 — Collection bin and compaction configuration

• Specify bin volume in containers , at a stated container mix assumption. Litres tell you nothing about how often a store employee empties it.
• Ask for compaction ratio under load together with the resulting container throughput per hour. Suppliers often quote these independently, which flatters both.
• Require fill-level sensing with a defined alert path (local, cloud, or both) and set a false-alarm tolerance you will accept during the pilot.
• Confirm bag/liner system availability and consumable part numbers. A bin you cannot re-line quickly is a recurring downtime item.
• Confirm the bin access door cannot be opened mid-payout, and that the design satisfies your retailer's cash-handling and access-control policy.

Item 5 — Communications and back-office integration

Name the protocol in the specification — REST, MQTT, or a documented vendor API — and require the interface document as a deliverable at shortlist, not a post-order courtesy. Then define offline behaviour in writing: how many transactions buffer locally, how refund authorisation degrades when the link is down, and how the buffer reconciles on reconnect.

Cybersecurity is a live procurement line, not an IT afterthought: HTF Market Intelligence's market commentary flags cybersecurity risk on cloud-connected recycling platforms as an ongoing manufacturer cost, alongside component price inflation and extended lead times ( HTF Market Intelligence ; publisher date not supplied). Ask for firmware update signing, remote-access controls and a data-minimisation statement. Require the data dictionary: which fields leave the machine, at what frequency, and who is the data controller. Ask which scheme or clearing-house interfaces are already implemented versus custom-built — and price the custom work as a separate line so you can compare quotes honestly.

Item 6 — Environmental, safety and market-access file

• Ask for the IP rating claim and the corresponding IEC 60529 test report. The report, not the badge.
• Require EMC and safety test evidence for the assembly as shipped, plus the CE declaration of conformity listing the standards cited. Distinguish a component-level certificate from a machine-level assessment — they are not interchangeable.
• Specify the operating temperature and humidity envelope, and ask whether the quoted figure was tested or modelled.
• For outdoor or canopy installations, ask for washdown and cleaning guidance and which surfaces degrade under alkaline cleaners.

Documentation gap warning: if a supplier cannot produce test reports on request at shortlist stage, expect the same gap at customs clearance or scheme approval, when you have no leverage left.

Item 7 — Jam clearing, cleaning and field-service design

• Set a target time-to-clear for the three most likely jams — intake, payout path, bin full — and require tool-free or single-tool access.
• Require a service manual and an exploded parts diagram with part numbers as contract deliverables.
• Ask for the preventive maintenance schedule and split tasks into store-employee-performable versus technician-only.
• Request the spare-parts list with lead times and a written obsolescence notice period. Long-term parts availability deserves its own negotiation, tracked separately in our lifecycle guidance; here, just confirm the notice period is contractual.
• Ask how the machine reports its own fault state before a consumer abandons a transaction.

Item 8 — BOM transparency, MOQ and lead time

Require a BOM split into sub-assemblies with named sub-suppliers for the recognition head, payout module, controller and display. You are buying a supply chain, not a box. Then ask which items are single-sourced and what the second-source plan is.

Get MOQ tied to configuration — enclosure, payout mix, colour, branding — rather than one headline number, and get lead time broken into tooling, build and test, with certification and acceptance testing shown as included or excluded. For budget framing only: a vendor blog cites $10,000–$30,000 for a basic RVM and $50,000 or more for larger, more advanced machines ( Wendor, 3 June 2026 ; publisher metadata unverified). Treat that as order-of-magnitude context, not an audited cost study, and never as a quote basis.

Item 9 — The factory acceptance test and the two-week pilot gate

Define both gates before you award the order.

1. FAT protocol: which container library, how many transactions, which failure modes count as a fail, who witnesses and who signs.
2. Pilot metrics you will actually measure: false rejects, false accepts, jam frequency, time-to-clear, payout mismatches, uptime across the two weeks.
3. Written sign-off sheet plus a remediation clause for items that pass the FAT but fail in live conditions — this is where most disputes land.
4. Escalation path during the pilot: named contact, response window, on-call hours.

Your own pilot data will be the only performance evidence specific to your market and container mix that you ever hold. Fund it properly.

Next step: ask for the documents, not the brochure

The shortlist test is simple. Send every candidate the same request: the hardware specification sheet, a BOM breakdown with named sub-assemblies, IP/EMC/safety test reports, a sample service manual, and MOQ and lead time split by stage. The suppliers who answer in documents move forward; the ones who answer in adjectives do not.

Usingwin Tech builds reverse vending and deposit-refund kiosk hardware on an OEM/ODM basis, including the payout and recycling module configurations described above. Our reverse vending machine OEM/ODM configuration and capability page sets out the enclosure, payout mix, recognition and communication options available for a market-specific build — send your container mix and target scheme market and we will map the configuration against them.

Request the RVM hardware specification sheet, BOM breakdown and sample-evaluation quote. Bring your container library and your acceptance criteria; we will quote to the configuration, not to a catalogue page.

Specification questions buyers ask before shortlisting

What container recognition rate should an RVM guarantee, and how is it measured?

No supplier can give you a publicly verifiable rate, and no scheme publishes a comparable one. Specify measurement instead: false-accept and false-reject counts on a container library drawn from your own market, run under a witnessed protocol with a fixed sample size. The guarantee you want in the contract is a test outcome, not a percentage.

Should the payout module handle coins, notes or both for a Pfand-style scheme?

It depends on deposit value and expected return volume per visit. High-cycle coin payout stresses hopper refill; note recycling stresses the acceptor path and jam access. Decide the payout mix from your deposit arithmetic and site footfall first, then require the module's part number, sub-supplier and dispense-cycle service data — for the specific module quoted, not the range.

What is a realistic MOQ and lead time for a custom RVM build?

Ask for both broken down rather than quoted as single figures: MOQ by configuration variable (enclosure, payout mix, branding), and lead time split into tooling, build, test and certification. Require the split in writing so you can see which stage a delay actually came from.

Which documents should I request from an RVM supplier before shortlisting?

Five, at minimum: the hardware specification sheet, a sub-assembly BOM with named sub-suppliers, the IP/EMC/safety test reports with the CE declaration, a sample service manual with an exploded parts diagram, and a written FAT protocol with pass criteria. A supplier who cannot produce these at shortlist stage will not produce them under pressure later.