Cashier payment-QR shift checklist - five minutes at shift start against sticker swaps, silent payment failures, and doctored backup codes

You are the head cashier of a coffee shop. Turn the
payment security shift check below into a tickable
checklist; every line states "what to do + what passing
looks like + what to do on an anomaly," for the opening
of every shift, about five minutes total. Store
parameters stay as 【】 placeholders.

Background (put it in the checklist header): a swapped
QR code, a dead announcement speaker, and a doctored
backup code are the three most common payment losses in
a store. The attacks take zero skill; the only defense
is the shift check.

1. Main payment QR (every shift start)
□ Appearance: check the stand and the counter sticker
  for second stickers, overlay films, lifted edges,
  wrong size - pass: matches the archived photo in
  the manager's "payment code archive" album
□ Test scan: scan 0.01 with your own phone and read
  the receiving account name - pass: it shows our
  store account, matching the archive; refund it via
  the backend immediately after
□ Arrival confirmation: wait for the voice
  announcement or backend notification - pass: fires
  within 30 seconds; if silent, check speaker power
  and binding, and verify each payment in the backend
  until fixed that day
□ On anomaly: the account name is not ours - stop
  using the code, pull the stand, photograph it
  exactly as found, call the manager, start the
  fallback flow (section 3)

2. Other payment entry points
□ Table codes and order-scan codes: spot-check 【2】,
  same test scan and account-name check - table
  codes live in customers' hands, the favorite swap
  target
□ Backup payment code: sealed and logged in normal
  times; test-scanned only when activated - nobody
  remembers what an unused code looks like, which is
  how a doctored one survives for weeks
□ Personal items out of the cash drawer: a personal
  QR code stored next to the store's is where
  unexplainable things begin

3. Anomalies and handover
□ Fallback card in place: the payment path when the
  main code is down (manual account entry / backup
  code activation steps) written on a card inside
  the register
□ Handover rule: any "customer says they paid but
  nothing arrived" dispute gets the backend
  transaction log checked before anyone replies -
  answering "can you check again?" without looking
  pushes a paying customer out the door
□ Evidence rule: for any code anomaly, photograph
  first (position and appearance), handle second -
  police reports and platform disputes both run on
  photos

Execution rules:
- The opening cashier executes and signs; the manager
  spot-checks the test-scan log weekly
- Every 0.01 test-scan refund is logged and reconciled
  against the backend at month end - unlogged, the
  check manufactures its own ghost variance

Constraints:
- Every line needs a tickable action and a pass
  standard; no "mind payment safety" slogans
- Invent no "platform regulations" or "police
  requirements" - platform procedures read "per our
  payment platform's backend steps 【】"

Why it is written this way

A QR swap costs the attacker one sticker, so the defense has to be cheap enough to sustain at five minutes a day. The checklist splits "a quick look" into three gates because each blocks a different failure: appearance catches sticker swaps, the test scan catches account misbinding and substitution, and arrival confirmation catches silent leaks. Looks-only checking fails exactly when the swapper also picked a convincing-looking sticker.

The 0.01 test scan is the strongest gate and the first one people skip - which is why its refunds must be logged: unlogged, a few stray cent-level transactions eat reconciliation time at month end, and the check dies of its own byproduct. A defense routine that cleans up after itself is the only kind that lasts.

The backup code gets its own line because its risk structure is the mirror image of the main code's: the main code is seen hourly and a swap surfaces within a day, while nobody remembers the backup's face, letting a doctored one live for weeks. "Seal when idle, test-scan on activation" is the only cheap answer - written into the checklist rather than kept in the manager's head, so activation actually gets checked.

The handover rule pins "customer says they paid" to backend-first because one reflexive "check again" reads to a paying customer as an accusation of dine-and-dash - the last link in payment loss prevention is keeping the customers who did pay. Photograph before touching anything, because both police reports and platform disputes run on evidence that cannot be re-shot later.

Variables