Skip to main content

Bill validators on gaming machines: recovering bills and tickets without losing a cent

A bill validator does something that looks simple: it takes a bill or a TITO ticket, decides whether it is valid and stores it in the stacker. The machine adds the credits and the player keeps playing.

Integrating JCM iVIZION and JCM UBA validators into an electronic gaming machine (EGM), the hard part was not accepting bills. It was recovery: what to do when a bill or ticket is left halfway by a power loss, a jam or a reboot.

A bill’s journey

Accepting a bill is not one step. Roughly:

  1. The validator takes the bill and recognizes it.
  2. It holds it in escrow and tells the machine the denomination.
  3. The machine decides whether to accept or return it.
  4. If accepted, the validator stacks it and confirms.
  5. The machine adds the credits and updates the meters.

Every step is a point where something can fail. If power drops between 4 and 5, the bill is already in the stacker but the machine never added the credits. If the order is designed wrong, the opposite can happen: credits added and the bill returned.

Tickets are more delicate

With a TITO ticket the journey is longer, because the casino system is involved:

  1. The validator reads the ticket barcode.
  2. The machine asks the casino system, over SAS, to validate the ticket.
  3. The system approves it and marks it as redeemed.
  4. The validator stacks the ticket and the machine adds the credits.

Now three parties have to agree: the machine, the validator and the casino system. If something fails between step 3 and 4, the system already considers the ticket redeemed, but the player does not have the credits yet. That ticket cannot be redeemed anywhere else, so the machine must finish the operation when it recovers.

Recover without guessing

The rule is the same as for NVRAM and printers: record the intent first, then act, then confirm. In practice:

  • Persist every state of the bill or ticket in NVRAM: in escrow, accepted, stacking, stacked, credited.
  • At boot, ask the validator first what state it ended in, before enabling play.
  • Reconcile against the record. If the validator says it stacked and the machine has no credits for it, credit them. If the machine already recorded the credits, never add them twice.
  • Finish what the system already approved. A ticket the casino already marked as redeemed has to be credited, even if the machine rebooted in the middle.
  • When there is no way to know, do not guess. Lock the machine with a clear event for an attendant to resolve, and log everything in the audit trail.

Jams and reboots

Power loss is not the only case. A jammed bill, a full or removed stacker, or a validator that reboots on its own leaves the operation just as unfinished. Each one has to end in a known state: the bill was credited, returned, or the machine is locked waiting for an attendant.

Recommendations

  • Design recovery first, not last. The happy path is easy; quality is defined by what happens when it is interrupted.
  • One source of truth per operation, stored in NVRAM, that the machine checks at boot.
  • Meters always consistent: bills, tickets and credits have to match the stacker contents and the casino system.
  • Test power cuts and jams at every step, with bills and tickets, and check credits, meters and the casino system state after each one.

Need help with validators or peripherals?

We are a Mexico City team, in US and Canadian time zones, working with manufacturers and game studios on SAS, peripherals (bill validators, TITO printers, button decks) and GLI certification. See what we do in SAS and EGM consulting, or read the practical guide to SAS on the EGM side.