Quick answer: A statute that says "must accept cash" is not enforceable in a specification. What makes it enforceable is a clause that names a metric, a test note set, both error rates, and the artefact the supplier must hand over. This page converts the 2026 legal language into those auditable fields — for US and EU self-service deployments — so you can reject a supplier whose "supports cash" line collapses under bench testing.
A statute that says "must accept cash" is not enforceable in a specification. What makes it enforceable is a clause that names a metric, a test note set, both error rates, and the artefact the supplier must hand over. This page converts the 2026 legal language into those auditable fields — for US and EU self-service deployments — so you can reject a supplier whose "supports cash" line collapses under bench testing.
Short answer: a cash-acceptance-compliant kiosk specification names, for every cash clause, the metric definition, the test note set, both the reject rate and the false-accept rate, and the audit-log retention baseline. If a clause cannot be tied to a supplier-delivered evidence artefact, it will not survive legal review — and it will not survive the bench test either.
Three questions to settle before the legal review meeting
Most failed cash specifications are not wrong about the law. They are unanswerable at the hardware level. The two dominant competitor formats — state-by-state law trackers and vendor pages promising "cash and cashless supported" — both leave you holding a clause that no engineer can test. Settle these three before anyone books a conference room.
1. What exactly is being measured?
An acceptance rate without a denominator is a marketing number. Ask: is the percentage calculated over notes presented or over first-presentation notes only? Does a retry count as a second presentation? Which firmware version produced the figure? Which denominations were in the mix? A single headline percentage, quoted without those qualifiers, cannot be entered into an RFP — and should not be accepted as a data point in a supplier comparison.
2. Which failure is costlier on this site?
A rejected genuine note costs you customer abandonment and a staff intervention. A false accept costs you cash loss and a reconciliation break. The two rates trade against each other in tuning, and the correct balance differs between a staffed retail counter and an unstaffed transit or parking terminal. Your specification must carry a target for both rates, stated against your own site's tolerance — not a single "accuracy" figure that hides the trade-off.
3. Who owns the evidence?
Does the supplier ship a per-model test report with the note set and firmware version named, or are you expected to generate that data yourself after delivery? If the answer is the latter, the compliance clause is decorative. Every requirement in the table below should have a named artefact attached to it at contract stage.
The nine evidence fields that separate a real cash spec from "supports cash"
Use this as a paste-ready supplier questionnaire. Each field is written so that a "yes" is verifiable and a "no" is visible.
| # | Evidence field | What the supplier must state in writing |
|---|---|---|
| 1 | Acceptance-rate definition | Denominator (notes presented vs. first-presentation notes), retry treatment, note set used, firmware version tested. |
| 2 | Test note set | Currencies, denominations, fitness mix (fit / unfit / limp / taped), and the named central-bank banknote-processing standard and edition the set is drawn against — named, not paraphrased. |
| 3 | Reject rate and false-accept rate | Two separate numbers, each with the conditions that produced it. A combined "accuracy" figure is not acceptable. |
| 4 | Cash-box and recycler architecture | Stacker-only vs. recycler; capacity per denomination (not per drum); throughput at projected peak, in notes/minute, not an idle-lab figure. |
| 5 | Anti-fraud and anti-fishing behaviour | Pull-back/stringing detection, note-retrieval blocking, shutter or escrow logic, and the defined action taken on detection. |
| 6 | Physical and cash-path security | Bezel and cash-path tamper sensing, lock standard, and how a forced-opening event is recorded. |
| 7 | Audit-log granularity | Per-transaction record contents, timestamp source, retention expressed in transactions and days, and the defined behaviour when the buffer fills. |
| 8 | Serviceability | Jam-clear access time, field-replaceable module list, recommended cleaning interval, and MTBF stated with its calculation basis rather than a bare number. |
| 9 | Firmware and banknote-series update path | How a new note series or fitness change is distributed, the notification commitment, the rollback procedure, and whether the update is signed and version-controlled. |
Mapping statute language to hardware parameters
A statute gives you an obligation; it never gives you a threshold. The table below keeps three columns only — the clause (with jurisdiction, date and verification status), the parameter that satisfies it, and the artefact that proves it. Where we could not source a clause to primary text, the row says verification required . Do not let a supplier convert that status into an assumption.
The euro-area base case
The ECB's Use of cash by companies in the euro area in 2026 (published 13 August 2026, ecb.europa.eu ) reports cash acceptance at 92% and card acceptance at 88% of physical points of sale, with mobile payment acceptance rising from 36% in 2024 to 68% in 2026. Its method is telephone interviews with companies — a stated-preference survey, not mystery-shopper measurement — so treat the figures as a market-context argument, not a hardware benchmark.
The same release is useful as a deployment-risk argument. Seven countries report 100% cash acceptance in restaurants while the Netherlands reports 78%; in retail, Greece and Slovenia report 100% while Belgium, Latvia, the Netherlands and Finland sit below 90%. That spread is precisely why a single EU-wide cash specification with one acceptance threshold is a weak instrument: the local cash mix, not the average, determines what your validator will actually face.
US state landscape
A secondary tracker ( cashcardkiosk.com ) lists nine states with statewide cash acceptance laws applying to at least some retail businesses or places of public accommodation: Massachusetts, Colorado, Connecticut, Delaware, Montana, New Jersey, New York, Oregon and Rhode Island — with materially different scope and exceptions. Treat that list as a lead requiring verification, not as a citation: for each state in scope, your counsel should read the primary statute text and confirm the covered establishments, the exceptions, and the effective date.
For New York specifically, a named law-firm summary (Holland & Knight, hklaw.com ) describes Senate Bill S4153A as covering "retail establishments" and "food stores," effective 120 days from signing (anticipated 20 March 2026), and prohibiting surcharging cash-paying customers. This is a secondary summary pending confirmation against the enrolled bill text — flag it as such in your compliance file.
| Clause (jurisdiction · date · status) | Hardware / firmware parameter | Evidence artefact required |
|---|---|---|
| EU market context — cash acceptance at physical POS, ECB release 13 Aug 2026 (published; survey method) | Acceptance rate per denomination across a fitness-mixed note set | Per-model test report naming note set and firmware version |
| New York S4153A — retail establishments and food stores, anticipated effective 20 Mar 2026 (secondary summary; verification required against enrolled bill) | Cash path present, functional and unblocked; receipt issued for cash tender | Configuration statement plus acceptance-test log |
| NY same statute — no surcharge on cash payers (secondary summary; verification required) | Software tender logic: cash price equals card price at the point of quote | Screen-flow walkthrough with price-comparison screenshot at the tested firmware |
| Other eight states — scope and exceptions vary (secondary tracker; per-state verification required) | Configurable acceptance and receipt rules per deployment | Per-market configuration matrix signed by the supplier |
| Cash-to-card conversion equivalence — jurisdiction-specific and asserted in vendor commentary (interpretive risk) | Not a hardware parameter. Do not map it to one. | Written legal opinion reference from your counsel, not a supplier brochure |
The last row matters more than buyers expect. Whether an on-site cash-to-card unit satisfies a cash-acceptance mandate is jurisdiction-specific, and the claim appears in vendor commentary rather than in settled statutory text. Require a written legal opinion reference in your file. Do not let a supplier's equivalence assumption become your compliance position.
Where specs fail in the field — and the clause that prevents it
- Lab-rated, unfit-note reality. A validator characterised on crisp notes meets a site whose cash mix is dominated by limp or damp notes. The fix is a fitness-mix test clause, not a higher headline percentage.
- Capacity quoted per drum, not per mix. A recycler sized on one denomination starves on the dominant denomination during peak. The fix is a capacity clause stated against your expected denomination mix at peak throughput.
- Log retention shorter than the reconciliation cycle. Records overwrite before the operator's cycle closes. The fix is a retention clause expressed in transactions and days at projected volume — plus the defined overflow behaviour.
- A new note series landing mid-deployment. The firmware path is undocumented and the rollout stalls. The fix is field 9 above: a signed-update and notification clause agreed at contract stage, with a rollback procedure.
RFP annex: acceptance test items to run on the sample unit
These are buyer-side acceptance tests. They do not substitute for any market certification, which must be listed per model with its issuing body and scope.
- First-presentation acceptance on the declared note set, per denomination, with the pass threshold written into the annex before testing starts. Record retries separately.
- Adversarial set: limp, folded, taped, wet-edge and mismatched-orientation notes, each scored separately, plus a deliberate stringing / pull-back attempt with the module's response logged.
- Sustained throughput at your projected peak rate for a defined duration, recording jams per 1,000 notes and jam-clear time with a stopwatch, not a datasheet.
- Forced-open and tamper simulation, verifying the event appears in the audit log with the correct timestamp and survives a power cycle.
- Firmware update applied to the sample unit, then test item 1 re-run to confirm the note set is not regressed by the update.
Our own bench method for these items is a matrix, not a single run: each denomination is exercised across fitness classes and feed orientations, with the cycle count per denomination fixed in the buyer's annex rather than chosen by the supplier. What gets logged is every presentation, its classification, the outcome, and the firmware build. These are internal characterisation runs — they are not a substitute for your own site trial, and we present them as method, not as a certification.
What we will and will not put in writing
We will provide: per-model acceptance and error-rate test reports with the note set and firmware version named; stacker and recycler capacity by denomination; the audit-log field list and retention configuration; tamper-event recording behaviour; service intervals and the MTBF calculation basis.
We will not provide: a blanket statement that a cash module makes a terminal, a site or an operator legally compliant. That depends on jurisdiction, signage, tender logic, surcharging practice and legal interpretation outside our scope. We are an OEM/ODM hardware manufacturer, not legal counsel, and the legal references on this page are research leads for your counsel to verify against primary sources. Acceptance and false-accept figures are model-, firmware- and note-set-specific and should never be generalised to a different configuration.
A compliant module is a necessary input, not the outcome. The most reliable route is to take the sample, run the annex above, and keep the report in the compliance file.
Request the 2026 cash-module compliance spec sheet and a sample unit for bench testing — alongside our cash acceptor and note recycler product range and OEM/ODM customization options. MOQ, lead time and customization scope are quoted per configuration, and we will supply the nine evidence fields above with the quotation so your legal review starts from data rather than adjectives.
FAQ
Does a cash-to-card kiosk satisfy a state law requiring businesses to accept cash?
It depends on the jurisdiction, and the question is legal rather than technical. Vendor commentary asserts equivalence for qualifying on-site conversion units, but we could not source that to primary statutory text. Your specification should require a written legal opinion reference for the specific state and configuration instead of treating the two as interchangeable.
What acceptance rate should a bill validator quote for a cash-accepting kiosk spec?
No single number is defensible, which is why the specification should demand definition rather than a headline. Require the denominator, the note set, the fitness mix, the firmware version and the retry treatment alongside any percentage — then verify the figure against your own adversarial note set on the sample unit.
Which US states require retail businesses to accept cash in 2026, and do the exceptions differ?
A secondary tracker lists nine states — Massachusetts, Colorado, Connecticut, Delaware, Montana, New Jersey, New York, Oregon and Rhode Island — applying to at least some retail businesses or places of public accommodation. Scope and exceptions vary substantially, so each state in your deployment footprint needs a read of the primary statute, not the list.
How does a note recycler change the compliance evidence compared with a stacker-only cash box?
A recycler adds two evidence requirements: capacity stated per denomination against your projected mix, and a payout accuracy and fitness rule for notes returned to customers. A stacker-only unit needs neither, but it cannot make change — which for many sites is the difference between accepting cash and genuinely serving a cash-paying customer.
