A serialized QR code alone tells you a code is valid. It doesn't tell you whether the physical product in someone's hand is the one that code was printed on. Here's how two different detection methods close that gap — and when to use which.
A serialized QR code — a unique, randomly generated identifier per unit — already beats a static code shared across a whole product line, since a counterfeiter can't just print the same image on every fake unit. But the image itself can still be photographed and reprinted. If a counterfeiter gets hold of one real unit, copies its exact QR code onto a batch of fakes, and those fakes reach different customers, every one of those scans still comes back as "valid" — because the code really is valid, just attached to the wrong physical product.
Closing that gap means adding a second signal beyond "is this code valid" — one of several authentication approaches covered in what product authentication actually means. QRTRAC's Scan to Verify ships two different ways to do that, and you configure one per batch depending on what fits your production process.
Each unit gets a second, separate code hidden under a physical scratch-off label — distinct from the printed QR code, and never exposed until the customer scratches it off.
This is the stronger of the two signals, because copying the visible QR code doesn't help a counterfeiter guess the hidden scratch-off value — they'd need physical access to an already-sold, already-scratched unit to obtain it, which defeats the point of counterfeiting at scale. The tradeoff is production: it requires a second printed element and a physically secure printing process, since the security depends entirely on the scratch-off code staying hidden until the real customer reveals it.
When a scratch-off label isn't practical, authenticity gets inferred from scan behavior instead of a hidden code.
The reasoning: a genuine unit gets scanned a roughly predictable number of times by its actual owner, while a QR code copied onto many counterfeit units gets scanned repeatedly, often from different locations, as it reaches different customers. Scan-threshold detection needs no extra printing step at all — it's pure configuration — but it's a probabilistic signal, not a direct one. A genuine customer who scans their own product several times out of curiosity can trip the same threshold a counterfeit does, so the threshold needs tuning to your product's realistic scan pattern.
| Scratch-Off 2nd Factor | Scan-Threshold Detection | |
|---|---|---|
| Signal type | Direct — a hidden code that must match | Probabilistic — inferred from scan behavior |
| Extra printing needed | Yes, a physically secure scratch-off label | No, configuration only |
| Customer step | Scan, then type in a hidden code | Scan only |
| False-positive risk | Low — a mismatch is a strong signal | Higher — needs threshold tuning per product |
| Best fit | High-value units where a print step is already justified | High-volume, lower-cost units where an extra label isn't practical |
If your unit economics already support a security print step — cosmetics, supplements, electronics, luxury goods — the scratch-off second factor gives you a much harder signal to defeat, since it doesn't depend on guessing normal scan behavior. If you're serializing a high-volume, lower-cost product where adding a second printed label isn't realistic, scan-threshold detection gets you real fraud signal for free, as long as you tune the threshold to how many times a genuine customer actually scans your product (once at unboxing looks very different from a product scanned repeatedly for warranty lookups).
Both methods report into the same Product Verification dashboard — total units, total scans, and flagged units with the reason, location, and timestamp of the scan that triggered the flag — so switching between them, or changing your threshold as you learn your product's real scan pattern, doesn't mean rebuilding your reporting. See the step-by-step setup guide for exactly where these settings live in the dashboard.
QRTRAC's Scan to Verify supports both scratch-off and scan-threshold detection on the same platform — switch per batch as your production process allows.