The Scanner You Already Own
A dedicated barcode scanner is a small purchase that quietly becomes a large one — one per counter, one per store gate, one that needs a driver. The phone in the storekeeper's pocket already reads barcodes. What it takes to make it type into the desktop, and where that stops being the right answer.
The quote for scanning hardware always looks reasonable on the first line and unreasonable by the last. One handheld scanner for the counter is affordable. One for the receiving bay, one for the back store, one for the second branch, a spare because the cable on the first one will fail, and a wedge that has to be configured to send the right suffix character — and the total has quietly become the kind of number that needs approving.
Meanwhile every person who would use one is carrying a device with a camera that reads a barcode perfectly well, and has been since roughly 2013. The obvious question is why that device cannot simply act as the scanner.
It can, and AWRA does it. But the interesting part is not that it works — it is what has to be true underneath for it to work safely, and that is the part worth understanding before you decide it is the right answer for your counter.
What a wedge scanner actually does
A conventional handheld scanner is not a clever device. It is a keyboard. It reads a barcode, types the characters into whatever field currently has focus, and presses Enter. That is the whole of it, and its simplicity is exactly why it has survived four decades of retail technology churn.
That simplicity has two consequences people rarely think about until something goes wrong.
- It types into whatever is focused. If the cursor is in the quantity box, the barcode goes into the quantity box. If a colleague clicked away, the barcode goes wherever they clicked. The scanner has no idea what it is scanning into.
- It cannot tell you anything. The scanner does not know whether the code matched an item, matched two items, or matched nothing at all. It types the characters and the screen deals with the consequences.
For a supermarket till scanning known products at speed, neither of those matters much, and a wedge scanner remains the right tool. For a storekeeper receiving a mixed delivery against a purchase order, both matter a great deal, because the questions they are actually asking are "is this the right item" and "is it on this order" — questions a keyboard cannot answer.
A handheld scanner is a keyboard that presses Enter. It has no opinion about what you scanned, which is fine at a till and a genuine problem at a receiving bay.
The linked-scanner idea
The pattern is straightforward to describe. Your desktop opens the screen you are working in — a check-in against a purchase order, say. It asks the server for a scan session. The server returns a token, and the desktop renders it as a QR code on screen.
You point your phone at that QR code. The phone claims the session, becomes the scanner for it, and from that moment every barcode the phone reads appears on the desktop screen, in the field that is expecting it, with the item already identified.
No pairing, no drivers, no cable, no device to lose. You walk the aisle with the phone and the desktop keeps up.
-
The desktop opens a session
The server generates a forty-character random token, stores the session against your organization and the user who opened it, and returns the token along with a six-character short code and a QR link. The session is now listening.
-
The phone claims it
Scanning the QR code sends the phone to a link page, which hands off to the app. The app exchanges that high-entropy session token for its own scanner credential — a separate sixty-four-character token which the server stores only as a SHA-256 hash. The plain value is returned to the phone once and never held on the server in readable form.
-
The phone scans, the server resolves
This is the part that distinguishes it from a wedge. The phone does not send characters — it sends a barcode to be resolved. The server looks it up within your organization and answers with what it is: an item, a purchase order, an adjustment, an RFQ, a quotation, with its identifier, its label and its current status.
-
The desktop collects the result
The desktop polls for new events, passing the identifier of the last one it saw. It receives up to ten at a time, and each is stamped as consumed the moment it is handed over, so the same scan is never delivered twice.
-
Someone closes the session
Closing it marks the session closed and revokes every scanner credential issued against it in the same action, so the phone stops being a scanner for that session immediately rather than eventually.
Why the resolution happens on the server
It would be simpler to have the phone send the raw barcode string and let the desktop screen work out what it means. The reason not to is that the phone and the desktop would then have to agree about what a barcode means, and they would drift.
Resolving centrally means one answer exists. A scanned code comes back as a typed thing rather than as text, and three specific situations get handled properly rather than accidentally.
| Situation | A wedge scanner | A resolved scan |
|---|---|---|
| Code matches one item | Types the characters; the screen looks it up | Returns the item, its label and its status |
| Code matches nothing | Types the characters; the field sits there wrong | Returns an explicit exception rather than a guess |
| Code matches two things | Types the characters; the screen picks one | Returns an ambiguity to be resolved by a person |
| Code is for a purchase order | Types the characters into an item field | Returns a purchase order, correctly typed |
The third row is the one worth dwelling on. Ambiguous barcodes are more common than people expect — the same manufacturer code across two variants, a supplier reusing a reference, an internal code that collided with a printed one. A keyboard cannot express "there are two of these"; it types the characters and something downstream silently chooses. Being told there are two, and choosing deliberately, is a materially different outcome from being told nothing.
The fourth row matters for a different reason. Because the resolution is typed, a scan can carry you into the right screen rather than into the right field. Scan an item and the answer comes back with the actions available for it — check it in, check it out, move it, count it, look at where it has been. That is a scanner that knows what you are holding, which is a different tool from one that knows what characters are printed on it.
The security shape of it, stated plainly
Turning a personal phone into an authorised scanner for a business system is exactly the kind of convenience that goes wrong quietly, so the constraints deserve to be published rather than assumed.
What is actually enforced
- The scanner credential is sixty-four random characters, stored as a SHA-256 hash. A database read does not yield a usable token.
- It carries a rolling expiry of forty-eight hours and a hard expiry of seven days. The hard one cannot be extended by continued use — after a week the phone re-links, whatever it has been doing.
- Closing the session revokes every credential issued against it, in the same operation.
- Claiming a session is rate-limited to twenty attempts a minute; the scanning endpoints to sixty a minute.
- Every session, credential and scan event is scoped to your organization, and a lookup carrying the wrong organization returns nothing rather than someone else's record.
- Each scan event is marked consumed when it is delivered, so a replayed poll cannot re-deliver a scan that was already actioned.
What AWRA OpsHub does today
- A phone becomes a scanner for a desktop session by reading a QR code, with no pairing, driver or cable.
- Barcodes are resolved on the server into typed entities — item, purchase order, adjustment, RFQ, quotation — with label and status, not returned as raw text.
- An unmatched or ambiguous code is reported as such, rather than resolved to a best guess.
- A resolved item carries its next actions — check in, check out, transfer, count, traceability — so a scan lands you in the right screen.
- Credentials are hashed, expire on a rolling forty-eight-hour and a hard seven-day basis, and are revoked when the session closes.
What it does not do
- A session does not expire on its own. It is created with no expiry and stays active until somebody closes it. The credential on the phone expires; the session waits. Close sessions as a habit rather than relying on them to lapse.
- Scans are collected by polling, not pushed. The desktop asks for new events and receives up to ten at a time. It is quick, but it is not a live socket, and at genuine speed you will feel the difference.
- No offline scanning into a linked session. The resolution happens on the server, so the link needs a connection at the moment of the scan.
Not ours, by choice
- We will not tell you to retire your handheld scanners. At a busy supermarket till a dedicated wedge is faster and more durable than a phone, and a software vendor claiming otherwise is selling you a downgrade.
- A phone is a personal device and we treat it as one. The credential is short-lived and revocable by design, because the alternative — a permanent scanner identity living on somebody's handset — is a liability dressed up as convenience.
A pushed event stream, and session expiry on a timer rather than on a close, are both scope rather than ceilings. The session, credential and event model are all in place and working; either change is a specification and a price.
The six-character short code is a convenience for typing a session in by hand rather than scanning it, and it is resolved as a prefix match within your organization, most recent first. The forty-character token behind the QR code is the exact one. If you have people typing short codes at a busy gate with several sessions open, prefer the QR.
Where this is the right tool, and where it is not
The honest framing is that a linked phone and a handheld wedge are good at different things, and the shape of your work decides which one you want. Neither answer is universal, and a business of any size usually wants both.
Reach for the phone
- Receiving a mixed delivery against a purchase order, where the question is "is this on the order" rather than "what is this".
- Anywhere the scanning happens away from the desk — a store gate, a back aisle, a yard, a second floor.
- Occasional scanning across many locations, where buying and maintaining hardware for each is disproportionate.
- Any situation where an ambiguous or unknown code needs to be noticed rather than absorbed.
- A pilot, before you know how much scanning you will actually do — because it costs nothing to try.
Buy the wedge
- A supermarket till at speed, where a dedicated scanner's ergonomics and durability win outright.
- High-volume repetitive scanning where a fraction of a second per scan compounds into real time.
- Environments where personal phones are impractical — cold rooms, wet areas, or where handling them is against your own policy.
- Counters where the cashier should not be holding a phone at all, for reasons that are about supervision rather than technology.
The test that settles it in an afternoon
Take one real delivery. Receive half of it with a phone linked to the desktop and half with whatever you use now, and time both — including the exceptions, not just the clean scans. The clean scans are where the wedge wins. The exceptions are where the resolved scan wins, and most teams find the exceptions were taking longer than they had realised.
What to decide before you roll it out
The technology is the easy half here too. What determines whether this becomes a habit or an experiment is a handful of decisions that somebody has to make in advance.
-
Decide whose phone
A personal handset is convenient and raises a question you should answer deliberately rather than by default. A shared store phone kept on charge at the gate sidesteps it entirely and is often the better answer for a receiving bay.
-
Make closing the session part of the task
Because the session waits rather than lapsing, closing it should belong to finishing the job — not to a policy nobody reads. Build it into how the task ends.
-
Prefer the QR to the short code
The short code exists for the times when scanning the QR is awkward. Where several sessions are open at once, the QR is the unambiguous one and it takes no longer.
-
Decide what happens on an ambiguous code
The system will tell you a code matched more than one thing. What the storekeeper does next — pick one, call someone, set the line aside — is a process decision, and being told about an ambiguity is only useful if there is an answer to what happens next.
-
Fix the codes the scanner keeps failing on
A code that comes back unmatched repeatedly is a catalogue problem, not a scanning problem. The value of being told is that you can fix the item record; the value is lost if nobody does.
The wider point about scanning
Scanning gets bought as a speed improvement and its real return is usually accuracy. A person keying a code from a label makes a mistake every few hundred entries, and the mistakes are invisible — a transposed digit resolves to a different real item, and the stock record is wrong for both of them until somebody counts.
That argument holds regardless of which device you use. The reason the linked-phone version is worth knowing about is that it removes the capital decision from the accuracy decision. You do not have to justify hardware for a store gate that receives twice a week; you can just start scanning there and find out whether it matters.
The receiving side of that argument is in receiving against a purchase order, the counting side in counting the shop without closing it, and the catalogue discipline that makes any of it work is in the till will not sell what you have not listed.
Our take
If you are scanning at a fast till, buy the wedge — it is the right tool and it is not expensive. If you are scanning anywhere else, start with the phone, because the marginal cost is zero and the exceptions get caught. The part of this worth understanding rather than assuming is that the resolution happens on the server: what comes back is a typed thing with a status and a set of next actions, not a string of characters, and that difference is what makes an ambiguous barcode a question rather than a silent wrong answer.
See the linked scanner working
A QR code on the desktop, a phone that becomes the scanner, barcodes resolved into items and orders with their next actions attached, and credentials that expire and revoke on their own terms.
Explore the linked scannerFrequently asked questions
Do we still need to buy barcode scanners?
For a fast supermarket till, yes — a dedicated handheld is quicker, tougher and better shaped for the job, and it is not an expensive piece of hardware. For receiving bays, back stores, yards, second branches and anywhere the scanning is occasional, a phone linked to the desktop does the work without a purchase order. Most businesses end up with both, and the useful thing is that you no longer have to buy hardware to find out whether scanning helps at a particular location.
How does the phone connect to the desktop?
The desktop asks the server for a scan session and displays the resulting token as a QR code. You scan it with the phone, which exchanges that token for its own scanner credential. From then on, barcodes read by the phone appear on the desktop screen. There is no pairing, no driver and no cable — the connection is a session on the server rather than a link between the two devices, which is also why either can be replaced mid-task without breaking anything.
Is it safe to use a personal phone as a scanner?
The constraints are designed for exactly that concern. The credential the phone holds is sixty-four random characters stored on the server only as a hash, it carries a rolling forty-eight-hour expiry and a hard seven-day one that continued use cannot extend, and closing the session revokes it immediately. Everything is scoped to your organization. That said, whether personal devices should be used for work at all is a policy question rather than a technical one, and a shared store phone kept at the gate is often the cleaner answer for a receiving bay.
What happens if a barcode matches two different items?
You are told. The resolution runs on the server and returns an explicit ambiguity rather than choosing one, which is the main practical difference from a conventional wedge scanner — a wedge types the characters and something downstream picks silently. Being told is only half the value, though. Decide in advance what a storekeeper does with an ambiguous code, and treat repeated ambiguities as a catalogue problem to fix rather than a daily inconvenience to work around.
Does the session close by itself?
No, and this is worth knowing. A scan session is created with no expiry and stays active until somebody closes it. The credential on the phone does expire — forty-eight hours rolling, seven days hard — but the session itself waits. Make closing it part of finishing the task rather than a rule in a document, and it will not become a problem.
Can we scan while the connection is down?
Not into a linked session, because the barcode is resolved on the server at the moment of the scan — that is what allows it to come back as an identified item rather than a string of characters. Offline capture in the mobile app is a separate mechanism covering four operations: stock transfers, check-ins, check-outs and asset movements. The full picture of what does and does not work without a connection is set out in [offline is a list, not a switch](/blog/offline-pos-kenya).
