Marketers Schedule QR Codes by Time Without Reprinting
Time-based QR codes switch on, switch off or rotate on a schedule. For marketing, we recommend server-controlled dynamic codes, where an expiry field such as “expiresAt” sits behind a stable link you can change at any time. Reserve TOTP rotating codes, which change every few seconds, for high-security entry, and use QRlytics for the campaign side.
TL;DR:
- For promotions, use a server driven dynamic code with activation and expiry rules; print times and timezone, and route expired scans to a fallback page.
- For tickets and payments, choose single use codes; reserve TOTP rotation for high risk entry, where live screens and synchronized clocks are available.
- Refresh dynamic codes a few seconds before expiresAt, use that timestamp for countdowns, and test clock differences, network delays, and scanning on multiple phones.
- Before choosing a provider, verify lifecycle controls, code permanence after cancellation, analytics export and retention for timestamped scans, API limits, and redirect uptime.
Table of Contents
- What are time-based QR codes, and which types exist?
- Where do scheduled QR codes earn their keep?
- How do time-based QR systems work under the hood?
- How should you schedule windows and design the scanning experience?
- What should you check before launch?
- What should you look for in pricing and product features?
- Why we favour permanence over cleverness
- How QRlytics helps with time-based QR campaigns
- FAQ
- Sources
- Developer docs and resources to consult next
What are time-based QR codes, and which types exist?
A static code holds fixed data and can never change or expire on its own. A dynamic code points to a short link that our server resolves, so you decide what it shows and when. TOTP-based rotating codes generate a fresh one-time value every few seconds from a shared secret.
- Static: simplest to make, but no scheduling, no edits and no analytics.
- Server-driven dynamic: easy to implement, flexible, and ideal for promotions, menus and print. Security depends on your server rules.
- TOTP rotating: can help limit the usefulness of screenshots and sharing, but it needs a live screen and synchronised clocks. Practitioner guidance contrasts this cryptographic approach with marketing-focused server-side scheduling, noting the trade-off between security and ease of implementation.
Match the technique to the job. A flyer needs a dynamic code, while a festival gate may justify rotation.
Where do scheduled QR codes earn their keep?
Scheduling matters whenever the offer, the audience or the access has a start and an end. These are the projects we see most often:
- Time-limited promotions and coupons. The code activates at launch and stops working after the sale, so late scans land on a “see our next offer” page instead of a dead end.
- Event and venue access. Rotating codes can make a screenshot less useful after the code changes, which may help limit ticket sharing at the door.
- Payment flows. Amount-locked, use-once dynamic codes are designed to associate a code with a single transaction.
- Gated content or timed access links. Webinar replays, early-bird downloads and member previews can open and close on a calendar without anyone editing a page by hand.
Each case can give you more control over when a code works.
How do time-based QR systems work under the hood?
Most implementations rely on a small set of fields and one repeating pattern. If you are briefing a developer or a vendor, ask about these:
- Access-code endpoints. Developer documentation shows responses carrying “content” (the string to render as a QR code), “format” (often “QR_CODE”) and “expiresAt”, an ISO 8601 timestamp. Your client reads “expiresAt” to start a countdown.
- Payment-style dynamic codes. The payment documentation describes a fresh, use-once code per transaction with “amount”, “useOnce” and an optional “expiryDate” that commonly defaults to 30 minutes.
- TOTP logic. Access-control documentation describes validity tied to a time-step window, where validation may accept adjacent windows to tolerate small clock drift.
- Refresh-before-expiry. Fetch a new code shortly before “expiresAt” rather than after it, and never on every render.
Pro Tip: Treat “expiresAt” as the single source of truth for your timer, and test with a deliberately short expiry before going live.
How should you schedule windows and design the scanning experience?
Good scheduling is mostly about removing surprises for the person holding the phone.
- Print the activation and expiry times in the campaign copy, in plain words and one timezone.
- Show a visible countdown wherever the code is displayed on screen, and refresh the code a few seconds before it lapses to absorb network latency, as the same developer guidance recommends.
- Allow for timezone offsets and for server and device clocks that disagree by a few seconds.
- Decide single-use or multi-use by fraud risk: single-use for payments and tickets, multi-use for general promotions.
An example of why it matters: the payment documentation describes expiry defaulting to 30 minutes for transactions, which shows how deliberately short windows are chosen when money is involved.
What should you check before launch?
Run this list before anything goes to print:
- Fetch and render. Call the access-code endpoint once when the screen opens, display the QR image and start the timer.
- Refresh strategy. Trigger a new request a few seconds before “expiresAt”, not on every redraw.
- Security. Use TOTP where entry is high-stakes. For payments, enforce “useOnce” and server-side checks, in line with ticketing practice and the dynamic payment docs.
- Analytics. Log timestamped scan events with a campaign identifier, and confirm you can export the data afterwards. Our guide to QR code analytics metrics shows what to capture.
Pro Tip: Scan every code on at least two phones, on mobile data as well as Wi-Fi, before approving a print run.
What should you look for in pricing and product features?
Scheduled campaigns put particular demands on a plan, so compare these points rather than headline code counts:
- Lifecycle controls: can you set activation and expiry dates in both the interface and the API?
- Permanence: do codes created during a subscription keep working after it ends? Our article on why QR codes expire explains how reprints happen.
- Analytics retention and export: can you pull timestamped scan data after the campaign closes?
- API access and reliability: check rate limits and how redirect infrastructure stays online. Uptime thinking from this hosting reliability guide applies directly to redirects.
Why we favour permanence over cleverness
Most marketing campaigns do not need rotating cryptography. They need a code that works when printed and a destination you can change. TOTP is right for gates and tickets, but for a poster, server scheduling plus permanence wins. Test code lifetimes and the scanning experience on a small batch before a wide print run.
— The
How QRlytics helps with time-based QR campaigns
Printed codes should never become your biggest risk, so we built QRlytics around codes that keep working. Here is what you get for scheduled campaigns:
- Dynamic URL updates, so a printed code can point somewhere new.
- Lifecycle scheduling for activation and expiry.
- Code permanence: check whether codes created during a subscription keep working after cancellation.
- Scan analytics with global heat maps.
You can start without a credit card. Create a QR code, run a timed test campaign, then compare plans on our pricing page.
FAQ
How much do dynamic QR codes cost?
Prices vary by provider and plan. We offer a Free plan at 0 $ per year; current Pro pricing is on our pricing page.
How does a dynamic QR code work?
The printed code holds a short link, not the final destination. When someone scans it, our server looks up the current destination and redirects, so you can edit or schedule it without reprinting.
How can you see how many times a QR code was scanned?
Use a dynamic code with built-in analytics, which logs each scan with a timestamp. Static codes do not provide scan data through a server you control. Our QR code tracking guide walks through the setup.
Do expired time-based QR codes stop working?
It depends on how they were built. A schedule on a dynamic code can show a fallback page after expiry, while a TOTP code simply fails validation once its window passes.
Sources
- Sport Alliance Developer Portal
- Dynamic QR
- QR Code - API Access Control Devices
- QR Code Ticketing System: Secure, Contactless Event Entry
Developer docs and resources to consult next
Test against the documentation rather than assuming default behaviour. These are the references behind the technical points above:
- The Sport Alliance developer portal for the access-code endpoint and expiry handling.
- The dynamic QR payments documentation for use-once codes and expiry dates.
- Control iD access API notes for TOTP windows and clock drift.
- Ticketing platform guidance on secure event entry.
- Our own QR API integration article on tracking campaigns without reprinting.