User Interaction and Reward Options for Reverse Vending Machines: Vouchers, QR Codes, NFC and APIs
A technical guide to vouchers, digital wallets and loyalty integrations in reverse vending

User Interaction and Reward Options for Reverse Vending Machines: Vouchers, QR Codes, NFC and APIs

A reverse vending machine is only as successful as the way people use it. You can have the best compactor and fraud‑prevention logic in the world, but if a pensioner can’t get their voucher, or a parent with children finds the flow confusing, they will simply walk away.

User interaction on an RVM has two critical jobs:

  • Make it fast and obvious how to return containers.
  • Make it simple and reliable to obtain the incentive (voucher, points, donation, wallet credit).

Recyclever RVM5 supports four core interaction methods, all designed to be usable by people of any age:

  • Printed voucher
  • Scan the QR on‑screen
  • Present phone, NFC or QR to an external reader
  • Key‑in on the touchscreen

This article explains each option, how it works technically, and when to use which in DRS and non‑DRS initiatives.

1. Why user experience matters as much as hardware

From a system point of view, an RVM has three pillars:

  • Hardware and compaction – accepting/refusing containers, sorting and compacting.
  • Fraud prevention and data – proving which containers were returned, by whom, and when.
  • User interaction – making the whole process feel obvious, quick and trustworthy.

If the interaction is poor:

  • Queues build up because vouchers take too long to print or screens are unclear.
  • Some users (older or less tech‑savvy) feel excluded if the scheme is “app only”.
  • Retailers get complaints at the till because people don’t know what to do with their tickets.

So the interaction design is not decoration. It is what converts container returns into a functioning business process.

2. DRS vs non‑DRS: different defaults

2.1. In DRS: printed vouchers as the standard

In DRS markets, RVMs are almost always installed in or next to supermarkets. The most robust and inclusive user interaction is:

  • Printed deposit voucher, redeemable directly at the till.

Characteristics:

  • No apps to install.
  • No need for a data connection on the user’s phone.
  • Works for all ages and demographics.
  • The customer simply hands the voucher to the cashier and gets the value deducted from the bill.

Yes, it uses paper, which is not ideal, but in the context of DRS:

  • The simplicity and inclusivity outweigh the paper downside.
  • Retail systems and staff training are already oriented around this model.

2.2. In non‑DRS: start simple, then add intelligence

In non‑DRS initiatives, there is no legally mandated deposit and no national infrastructure. Here, Recyclever generally recommends:

  1. Start with a static printed voucher

    • Very low IT effort.
    • Easy to understand.
    • Ideal for pilots and early roll‑outs.

  2. Then move to logic‑based vouchers or app integrations

    • Once the initiative proves itself.
    • When there is a clear POS or app ecosystem to connect to.

Using apps for rewards can be powerful, but only if the target population already uses that app. Otherwise, you risk excluding a large fraction of potential users.

3. Static printed vouchers: the simplest path

A static voucher is a printed ticket without live integration to any external system.

Characteristics:

  • The barcode (if any) is always the same, or there is no barcode at all.
  • Content is defined by the RVM: for example:
    • Date and time down to the second
    • Site or machine ID
    • Number of containers or total value

Redeem is manual:

  • A member of staff at the till or redemption point checks the voucher and applies the value manually in their system.

3.1. When static vouchers make sense

Static vouchers are ideal for:

  • Early pilots with a small number of machines.
  • Events and temporary initiatives.
  • Non‑DRS schemes where IT budgets are limited.
  • Some larger deployments in countries with simple retail systems.

They are:

  • Easy to set up (no APIs, no POS integration).
  • Robust (few failure points).
  • Instantly understandable for users.

3.2. Fraud considerations and mitigation

Static vouchers are more open to fraud than logic‑based ones, but there are ways to reduce risk:

  • Use custom voucher paper from Recyclever so authentic vouchers are visually recognisable.
  • Print high‑precision timestamps (down to seconds) and machine identifiers.
  • Print location‑specific information:
    • Each machine can print a specific “redeem here” location.
    • This makes simple photocopying less effective: taking copies around town is harder if vouchers point to different redemption points.

The result is a low‑IT solution that is still difficult to exploit at scale, especially if staff are trained to check basic details.

4. Logic‑based printed vouchers with barcodes

A logic voucher is a printed ticket with a unique, machine‑generated code that is validated by the retailer’s POS or another back‑end system.

Typical flow:

  1. The user finishes a session, e.g. 10 bottles.
  2. Each bottle is worth 0.05, so the total is 0.50.
  3. RecyHub (or the RVM) asks the POS or voucher server via an API:
    • “Please issue a voucher for 0.50.”
  4. The POS/voucher system returns a unique code.
  5. The RVM prints that code as a barcode and/or human‑readable string.
  6. At the till, the barcode is scanned. The POS validates it, marks it as redeemed, and applies the discount.

4.1. Technical notes

  • The barcode format is typically standard (e.g. Code128, EAN‑13, or similar), but the exact type and payload can be configured.
  • Recyclever provides a standard API map, but it is easy to adapt:
    • Different POS vendors.
    • Different value logic (per container, per material, per campaign).

The “truth” about voucher validity normally resides in the retailer’s POS or voucher back‑end:

  • They guarantee uniqueness.
  • They manage expiration and redemption status.
  • They may rotate codes or use formats that are hard for users to guess or reuse across different shops.

4.2. Advantages

  • Strong fraud control: each voucher code can only be redeemed once.
  • Clean integration to store accounting and reconciliation.
  • Good user experience: paper voucher flow is familiar, but smarter underneath.

5. QR code on the screen: digital vouchers and app integration

Instead of printing a ticket, the RVM can show a QR code on the touchscreen at the end of the session.

5.1. Typical flow

  1. Session finishes: e.g. 10 containers.
  2. The RVM or RecyHub calls an app portal or reward platform via API:
    • “Create a transaction for 10 containers” (or for a certain value).
  3. The platform returns a unique token, which the RVM encodes as a QR and displays on the screen.
  4. The user scans this QR with:
    • The dedicated app, or
    • The phone camera which opens a web page.
  5. The external platform:
    • Recognises the token as “worth 10 containers”.
    • Associates it with the logged‑in user.
    • Updates their balance, points, or wallet.

Alternative pattern:

  • The QR displayed is a URL + embedded number (e.g. “10”).
  • The app on the phone is already authenticated.
  • When the URL is opened, the platform knows which user is calling and credits them automatically.

In all cases, the RVM’s job ends when it displays the QR. The app ecosystem handles identity, balances and rewards.

5.2. When QR on‑screen makes sense

QR on‑screen is attractive when:

  • The target users already use a specific app (retailer app, loyalty app, municipal app).
  • You want a fully paperless experience.
  • The user base is comfortable with smartphones and scanning codes.

5.3. Pitfalls

  • It requires careful flow design and development time for the app side.
  • Users without smartphones, or without the right app, are at risk of being excluded.
  • Screen readability and short display time must be considered for accessibility.

For inclusivity, QR on‑screen is often best combined with another option (e.g. printed voucher fallback).

6. NFC / QR user recognition: sending sessions directly to an app

Another powerful option is to flip the sequence: instead of showing a QR at the end, the RVM lets the user identify themselves to the machine, then sends session data out.

This is where the NFC/QR reader (user recognition) comes in.

6.1. Typical flow

  1. The user returns containers as normal.
  2. Session ends: e.g. 10 containers.
  3. The user presents their phone or card to the external NFC/QR reader:
    • NFC tap (phone or card).
    • QR or barcode displayed in their app and scanned by the reader.
  4. The RVM sends a simple payload via API to the external platform, such as:
    • user_id=1234
    • containers=10
    • Time, site, machine ID.
  5. The external system:
    • Credits the user.
    • Updates balances and any loyalty logic.
    • Stores all relevant analytics.

In this model, the RVM does not manage balances. It only asserts: “user X has just returned Y containers, under these technical checks.”

6.2. Use cases and caveats

This approach is very clean technically, but:

  • It assumes users already have and use the relevant app or card.
  • It may exclude those who are not digitally engaged.

So the question is always: “Does every intended user have this app or ID?”
If the answer is no, you need a more inclusive fallback, often paper.

7. Key‑in on the touchscreen and digital wallets

In markets where digital wallets linked to phone numbers are common, there is another option:

  • Key‑in on the touchscreen

Typical flow:

  1. Session ends: 10 containers.
  2. The RVM prompts:
    • “Enter your phone number” (or another unique identifier).
  3. The user types their number on the touchscreen keypad.
  4. The RVM sends:
    • phone_number=+XXYYYYYYYY
    • containers=10 (or value)
      to the digital wallet provider via API.
  5. The wallet platform:
    • Recognises the phone number as a user account.
    • Credits the associated balance with the correct amount.

This method:

  • Requires no app installation for users (only a phone number linked to a wallet).
  • Is very suitable in countries where mobile wallets are widely adopted.

Again, careful thought is needed for:

  • Data protection (handling phone numbers securely).
  • Validation (e.g. via SMS or pre‑registered numbers).

8. Choosing between printed, QR, NFC and key‑in

There is no one‑size‑fits‑all solution. The right choice depends on:

  • Who the users are

    • General public vs employees vs members of a specific club or scheme.
    • Age distribution and digital literacy.

  • What infrastructure already exists

    • Is there a widely used retailer app or loyalty platform?
    • Are digital wallets commonplace and trusted?
    • How complex or simple is the POS environment?

  • How inclusive the scheme must be

    • Public‑facing initiatives typically need at least one fully non‑digital path (printed voucher).
    • Closed groups can rely more heavily on apps and digital IDs.

8.1. Recyclever’s general recommendations

  • DRS

    • Default: printed logic voucher integrated with POS.
    • Simple, inclusive, robust, no phone requirement.

  • Non‑DRS pilots and early roll‑outs

    • Default: static vouchers with minimal or no barcode logic.
    • Keep it simple, prove the concept, then invest in APIs and apps.

  • Advanced non‑DRS initiatives with strong digital adoption

    • QR on screen to an existing app,
    • Or NFC/QR user recognition + direct API to loyalty or reward platform,
    • Or key‑in to digital wallets where phone‑linked wallets are standard.

9. Hybrid models and additional engagement features

9.1. Hybrid rewards: voucher plus points

Hybrid setups can be powerful but must be designed carefully to avoid confusion.

A recommended pattern is to define one primary reward (for example, printed voucher), and then add digital rewards on top:

  • The RVM always prints a voucher.
  • Optionally, if the user scans their phone or card (NFC/QR reader), the system also:
    • Credits 1 point per container to a loyalty app.

This opens interesting analytics:

  • A loyalty platform could compare what a user buys with what they return.
  • For example:
    • They buy Coca‑Cola under their loyalty account.
    • They return mostly Pepsi bottles.
    • This suggests cross‑shopping behaviour at different stores.

The key is to keep messaging at the RVM crystal clear:

  • “You will always get a voucher; if you also scan your app, you will get additional points.”

9.2. Donations to charity

The touchscreen can offer options such as:

  • “Donate your refund to charity”
  • Or split options, e.g.:
    • 50% to voucher
    • 50% to a chosen charity

Technically:

  • The RVM records the donation choice.
  • RecyHub aggregates this data.
  • The retailer or operator uses periodic reports to transfer funds to the charities.

This is a powerful way to:

  • Engage users who are less interested in personal rewards.
  • Demonstrate social impact in ESG reporting.

10. Design principles: inclusive, fast, trustworthy

Across all of these options, Recyclever’s design principles for user interaction are:

  • Inclusive by default

    • Paper‑based options available for everyone.
    • Digital options layered on top where they really add value.

  • Fast and reliable

    • High‑speed container processing and immediate reward issuance.
    • Clear on‑screen feedback for “accepted” vs “rejected”.

  • Simple for all ages

    • Large, readable touch‑screen prompts.
    • Multi‑language where needed.
    • Obvious, short flows: insert, finish, get reward.

  • Technically robust

    • Standardised, well‑documented APIs for POS, apps and wallets.
    • Logic centralised in RecyHub and/or client back‑ends to keep RVM logic clean.
    • Minimal points of failure at the machine.

If you get these right, the RVM becomes a pleasant habit rather than a chore, and the collection initiative has a real chance of long‑term success.

Read more

Designing an RVM Collection Initiative (DRS and non‑DRS)
How to specify an RVM‑based collection initiative end‑to‑end: operating modes, DRS vs non‑DRS, fraud prevention, logistics, business model and success metrics.

RVM Material Flows Explained: PET, Aluminium, Glass (Refill vs Recycling) and Carton/Tetrapak
Technical deep‑dive into how PET, aluminium, glass and cartons behave in an RVM, why separation matters, and how compaction and material choices affect real recycling and logistics.

RVM Compaction Technology and CO₂ Impact
Inside the RVM5 compactor: how tuned blades, chambers and plates deliver high density, prevent fraud, and reduce transport emissions.

RecyHub: Data, Telemetry and Analytics for RVM Fleets
How RecyHub collects and distributes data from RVM5 machines: events, vouchers, user interactions, telemetry and APIs for POS, loyalty and digital wallets.


RVM Material Flows Explained: PET, Aluminium, Glass (Refill vs Recycling) and Carton/Tetrapak
A technical deep‑dive into selective collection, separation design and downstream recyclability