Quick answer: A cash dispenser module pays out from pre-loaded cassettes and suits payout-only flows. A recycler re-issues notes the same kiosk accepted, so it suits sites that both take and give cash. An acceptor is cash-in only. The choice fixes cabinet envelope, cassette frame, lock strategy, CIT cadence and the service plan.
A cash dispenser module pays out from pre-loaded cassettes and suits payout-only flows. A recycler re-issues notes the same kiosk accepted, so it suits sites that both take and give cash. An acceptor is cash-in only. The choice fixes cabinet envelope, cassette frame, lock strategy, CIT cadence and the service plan.
That is the whole decision in one paragraph — and it is why the module choice belongs at architecture freeze, not in the procurement spreadsheet three weeks before tooling release. This page covers the integration-and-specification layer: what a module swap invalidates, which of your own operational numbers drive the pick, how the XFS interface split constrains the software stack, and what to put in the RFQ. The cost-per-unit and refill-economics comparison of acceptor, recycler and dispenser is a separate question and is handled in our running-costs comparison; if you are still deciding whether cash handling is worth it at all, start there.
The decision happens at cabinet freeze — here is what a late change costs
The ranking pages on this query stop at "a recycler reuses deposited notes." The architect's actual problem is different: a module change after the enclosure drawing is released is not a component swap, it is a re-validation project. These are the artefacts a dispenser-to-recycler change puts back on the table:
- Enclosure depth and note path. A dispenser moves notes one way. A recycler adds a return path, so transport geometry, bend radii and note-guide tooling must be designed around two directions from day one.
- Cassette frame and mounting. Recycle units, mixed-denomination units and plain dispense cassettes rarely share the same frame, latch pattern or extraction direction.
- Safe and lock interface. The lock strategy, the door aperture and the chain-of-custody boundary around the cassette stack are set by which module sits behind the door.
- Power budget and harness routing. Additional motors, sensors and a validator path change the current draw and the harness trunking inside the cabinet.
- EMC and safety clearances. Any change to internal layout and harness routing can invalidate the test position you already paid for.
- Service access and clearance zone. Jam clearance on a recycler needs a bigger working envelope in front of the kiosk — a floor-plan constraint, not just a cabinet one.
The schedule consequence is consistent: enclosure validation restarts, and the downstream site survey, safe-lock certification and service-contract negotiation all wait on it. One-line rule for the design review pack: freeze the cash architecture before the industrial design review, not after it.
Four numbers to pull from your own operation before you compare modules
No vendor can tell you which module fits; the numbers live in your transaction log. Collect four before you open a single datasheet.
- Deposit-to-payout ratio per shift. Count transactions in each direction. A payout-dominant site gains little from recycling; a roughly balanced site gets the most use out of it. This ratio alone eliminates one architecture in most projects.
- Notes handled per peak shift — count notes, not currency value. A high-value, low-note-count site and a low-value, high-note-count site can share the same turnover and need completely different unit counts.
- Tolerable interval between manual refills or CIT visits. This is set by your cash-in-transit contract and site access rules, not by the module. Write down the number you are actually contracted to, then test the module against it.
- Acceptable downtime, and who clears the jam. First-line store staff, a roving technician, or module swap by a trained engineer — each implies different access design and spare inventory.
On CIT economics, be sceptical of any figure you find online. No public benchmark for cash-in-transit cost per site is reliable across markets, currencies and contract structures, so a percentage "saving" quoted in a vendor deck should not enter your business case. What works instead: run a two-week note-count log at one representative site — counts per shift, direction, reject reasons — and use that log as the input to your float and visit-interval model. It is your data, your conditions, and it survives scrutiny from finance.
Dispenser vs recycler module: comparison by real decision criteria
Read this table as a design-consequence map, not a spec sheet. Every cell is qualitative on purpose; capacity, speed and life figures must come from each vendor's datasheet together with the test conditions it was measured under.
| Decision criterion | Cash dispenser module | Cash recycler module |
|---|---|---|
| Cash direction supported | Payout only | Cash-in and payout from the same note pool |
| Unit architecture | Dispense cassettes only | Cash-in unit, recycle units and often at least one dispense-only unit for denominations the site does not recirculate |
| Float tied up on site | Higher — every note paid out is pre-loaded | Lower steady-state float, because deposited notes are recirculated |
| Refill / CIT dependency | Driven purely by payout volume | Driven by net outflow; a balanced site refills less often in principle, subject to your contracted cadence |
| Cabinet footprint and note-path complexity | Simpler single-direction path, shallower envelope | Two-direction path, larger envelope, more guide tooling and more jam-access space |
| Lock and safe implications | Cassette keying and chain of custody are the whole security boundary | Same boundary plus a validator path, so the door aperture and audit trail cover more of the note journey |
| Jam recovery and service access | Fewer note paths to clear | More paths; define who opens the cabinet and how each opening is logged |
| XFS interface footprint | CDM only | CDM plus CIM in most implementations, or recycling units addressed through either interface |
| Multi-currency / multi-denomination handling | Cassette-per-denomination, configured through the dispense interface | Recycle configuration should be driven through the CIM interface when multiple currencies or denominations are involved |
| Software state model | Static float assumption is workable | Needs a live unit-status model, because inventory changes with what customers deposit |
| Best-fit flows | Payout-only: gaming cage payouts, ticket or voucher redemption, change dispensing | Mixed flows: bill payment with cash-in, self-checkout with cash acceptance, deposit-and-withdraw kiosks |
Where recyclers bite during integration
The XFS split is the part competitors skip, and it is the part that constrains your software team. Under the CEN CWA 16926-5 CashDispenser specification, cash-in unit counts are set through the CIM interface and cash-out unit counts through the CDM interface; recycling cash units can be addressed through either, but when a device carries recycle units of multiple currencies and/or denominations — or multiple note identifiers mapped to the same denomination — the specification directs configuration through CIM. Read the primary text before you argue with an integrator about it: CEN CWA 16926-5, CashDispenser (CDM) specification . Practical consequence: a multi-denomination recycler is a CIM-centric integration, so your middleware and back-office mapping need to be scoped for it — not treated as a dispenser with extra cassettes.
Beyond the interface, four integration items surface repeatedly:
- Note fitness and rejection. Notes the recycler refuses still exist physically. Define where they go, who removes them, and which reconciliation entry records them.
- Note-mix drift. The recycler's inventory is a function of customer behaviour, so the software must read live unit status rather than assume a fixed float.
- Firmware and counterfeit-database update policy. Ask who pushes updates, over what channel, and what happens to stored notes and open transactions during an update window.
- Serviceability and audit. More note paths mean more openings. Specify the audit-log format your back office must ingest at the same time as the hardware.
Where dispensers bite during integration
- Float reconciliation does not disappear, it moves. Every note paid out was counted and loaded upstream, so the cash-office workload relocates to the loading process.
- Empty-cassette outage. Define the low-cassette threshold, who is alerted and who responds — otherwise the kiosk becomes a signage board with a screen.
- Payout-only UX mismatch. A dispenser cannot absorb the cash customers arrive with. If the journey includes cash-in, pair it with an acceptor module or accept manual handling and staff time.
- Cassette keying and chain of custody. Physical cassette control is the entire security boundary here, so specify keys, seals and swap procedure inside the enclosure design, not after it.
Service model and cash-logistics line items buyers forget
Three things get agreed too late. First, first-line fix versus module swap: a recycler generally pushes the operator toward a heavier spare-module decision, and that needs a number in the service contract, not a verbal assumption. Second, contract the refill or CIT cadence against the chosen module and write the cadence assumption into the service level — it is the assumption most likely to be wrong once live volumes appear. Third, spares and lead time belong in the OEM agreement: ask for module lead time separately from cabinet lead time, because they are different supply chains.
Scope boundary, stated plainly: module warranty covers the module. It does not cover cash discrepancies, float loss or reconciliation errors. Any vendor implying otherwise is selling you a service model they cannot honour.
Procurement checklist to send the module vendor
- Datasheet with test conditions — note capacity per unit, accept and dispense speed, recycle-unit count, supported denominations, operating temperature and humidity range.
- XFS version supported, and whether recycler units are exposed via CIM, CDM or both; ask for the interface documentation reference, not a verbal answer.
- MOQ, module lead time, cabinet-level integration support, and who owns EMC and safety re-validation when the module changes.
- Counterfeit-database update mechanism and channel, note-data handling, and the audit-log format your back office must ingest.
- Spare-module and consumable pricing structure, plus the maintenance procedure and expected intervention time for a note-path jam.
- Reference deployments in your segment, with the operator willing to take a call.
Three quick scenarios show how the constraint shifts. A gaming cage payout kiosk is payout-dominant, so cassette capacity and the chain-of-custody around cassette swap dominate, and the enclosure can stay shallow. A retail self-checkout with cash-in is mixed but note-heavy, so recycle-unit count and rejection handling dominate, and the cabinet grows. A bank lobby bill-pay alcove carries multi-denomination and audit requirements, which pushes the design toward a CIM-driven recycler configuration and a stricter opening log.
Questions buyers ask before the architecture review
Is a cash recycler module the same as a cash dispenser?
No. A dispenser only pays out notes loaded into it. A recycler validates and stores deposited notes and re-issues them, so it supports both cash-in and cash-out — which is why it changes the cabinet envelope rather than just the bill of materials.
Can a dispenser kiosk be retrofitted with a recycling module later?
Sometimes, but treat it as a redesign. The return note path, cassette frame, door aperture, harness routing and EMC test position all need re-validation, so the retrofit is rarely cheaper than specifying the right module at freeze.
How many cassettes or recycle units does a cash kiosk need?
Derive it from your own note counts per peak shift and your contracted refill interval, split by denomination and direction. Ask the vendor to model unit count against your two-week note log rather than quoting a standard configuration.
Does a recycler really reduce cash-in-transit visits?
It can, because deposited notes are recirculated instead of every payout note being pre-loaded. The size of the effect depends on your net outflow and your CIT contract, and no public benchmark for cost per site is dependable — measure your own mix before assuming a reduction.
Which interface will our software team have to support?
Expect CDM for cash-out, CIM for cash-in, and CIM as the configuration path for multi-currency or multi-denomination recyclers. Confirm the supported XFS version and documentation with the module vendor in writing.
Next step: send your transaction mix
Send your transaction mix and request a module recommendation plus quote. Specifically: deposit-to-payout ratio per shift, notes handled per peak shift by denomination, required refill or CIT interval, jam-response model, and the market you deploy into. We will come back with a module configuration, cassette or recycle-unit count, the XFS interface footprint your software team must support, and a note on what your cabinet design has to accommodate. Module recommendation and quote requests are handled through our cash recycling kiosk OEM/ODM development and module integration service — include your target deployment date so lead time can be quoted separately from cabinet lead time.
