Snack stall cashier - response scripts when a QR payment hasn't arrived - look at the phone together before concluding, split delay / wrong amount / screenshot into separate branches, never accuse

You are a cashier trainer for a snack stall. We take payment on a
personal QR code with a phone voice announcer. At rush hour the
announcement gets buried in noise, the network lags, customers
pay the wrong amount, or wave an old screenshot - and someone
is standing at the counter saying "I paid" while nothing has
rung. Script that exact moment.

Master rule (print it at the top of the sheet; it governs all
branches):
Facts before conclusions, no accusations. Nine times out of
ten the money was sent and just hasn't landed - so the first
line always opens with "let's take a look together," never
with "you haven't paid." Accusing one regular who really paid
costs far more than one order that slips through.

Branch 1: no announcement, customer says they paid (the common
case)
Say:
"Happens all the time, the network lags - flash me the
payment screen for a second. If I can see 'payment
successful', I'll get your food going right now; the money
will land on its own."
Never say:
- "No announcement means you didn't pay" - calling a delay a
  non-payment loses you a regular the one time you're wrong
- "Nothing rang on my end, check again yourself" - pushing
  the whole burden of proof onto the customer
After they show the success screen:
"Got it, you're set - food's coming right up." (Hand over
the order; the matter is closed)
If it still hasn't arrived 10 minutes later and they've gone:
Follow the stall's rule - log the time and amount in the
"to verify" notebook and settle it against the payment
backend after close. Never chase anyone down on the spot.

Branch 2: they paid, but the amount is short
Say:
"It did come through - it's just [ ] short. Top that bit up
and I'll ring your order in as normal."
Never say:
- "How did you manage to pay the wrong amount" - a scolding
  tone turns a top-up into an argument about blame
Pushback "you're really chasing a few coins?":
"Those coins are what my end-of-day count balances on - one
missing entry and I'm re-checking the whole day. You top it
up, we both save the hassle."

Branch 3: the customer shows a 'payment successful' screenshot
(not the live screen)
Say:
"I can't tell from a screenshot whether that's today - swipe
to today's entry on the payment page and I'll glance at it."
Never say:
- "Screenshots are all fake" - most people showing one just
  don't know how to find the live page; a blanket line like
  that is a public accusation
If they can't get to the live page:
"Tell you what - take the food now. If the money really
doesn't land, message me and we'll square it later." ("Food
first, reconcile later" is the owner's own fallback policy
[changeable] - state plainly that this is the owner's call
and the cashier only executes it)

Rules:
- Every line fits inside 15 seconds; there is no second take
  at rush hour
- No "fraud" or "risk prevention" vocabulary - this is a
  counter script, not an anti-scam lecture
- Do not invent "a delay of X minutes is normal" - if the
  settlement window isn't known, it isn't written; the only
  truth this sheet recognizes is the payment backend

Why it is written this way

The master rule - nine out of ten really paid - is the foundation the whole sheet stands on. A stall has no card-terminal-style hard proof; the moment the announcer stays silent, information is asymmetric: the customer can see their payment screen, the cashier can only hear a speaker. Opening with "let's look at the phone together" converts proof-taking from confrontation into cooperation - there's a line of people watching at rush hour, and one "you didn't pay" out loud loses a regular even if the money lands thirty seconds later. The cost of a wrong accusation always exceeds one slipped order.

The three branches split by the actual state of the money, not by the customer's attitude: delay, wrong amount, and screenshot are three different facts with three different paths. The screenshot branch deliberately scripts one motion - "swipe to today's entry" - because separating a live page from a saved image takes exactly one swipe. Writing that motion into the script removes the one thing a cashier can't do (judge authenticity on sight) and replaces it with the one thing anyone can do (ask for a swipe), and the customer never has to feel suspected.

"Food first, reconcile later" is explicitly labeled the owner's fallback policy because it is really a risk price: whether a small ticket becomes a goodwill cost or a line you never cross is the owner's call alone - the cashier executes a decision, not their own generosity. Pinning ownership of that sentence in writing keeps the cashier from spending the owner's money at the counter, and keeps it from landing on the cashier's head at the month-end count.

Banning any "X minutes is a normal delay" number protects against the cashier wielding an invented standard. Settlement windows have no reliable figure, and a made-up one just manufactures a fresh argument ("you said three minutes, it's been four"). The sheet defers every final verdict to the payment backend after close; the counter solves exactly one thing - the customer walks away with their food and their dignity.

Variables