How to Use Dynamic Barcodes in Wallet Passes to Prevent Fraud

A static QR code on a wallet pass has a fundamental security flaw: anyone with access to the pass — even for a moment — can screenshot the barcode and share it. One event ticket becomes five. One loyalty card becomes a shared resource across a household. One premium membership gets used by people who have never paid for it. Dynamic barcodes solve this by making the barcode value time-sensitive — a screenshot taken two minutes ago is already invalid. This guide explains how they work and when to use them.

The fraud problem with static barcodes

Static barcodes encode a fixed value — typically a pass ID or member number — that never changes. When a customer screenshots their wallet pass and shares it with a friend, both people now have a valid barcode. If your scanning system checks only “does this barcode exist in our database?”, both will scan successfully.

This is not a theoretical edge case. Event promoters see screenshots of tickets circulating on social media. Gym operators find multiple people scanning the same membership barcode from a shared screenshot. Coffee shops running loyalty programmes discover that friends share a single card to accumulate points faster.

The magnitude of the problem scales with the value of the pass. A stamp card for a free coffee is a low-stakes target. An event ticket worth £150 or a gym membership worth £600 per year is a meaningful financial incentive to circumvent the system.

How dynamic barcodes work

A dynamic barcode replaces the static pass ID with a time-based token that expires after a short interval — typically 30 to 60 seconds. The token is generated using HMAC-SHA256: a cryptographic hash function applied to the pass ID combined with the current time bucket.

The mechanics are as follows. Your server defines a time bucket — for example, the current Unix timestamp divided by 30, giving a new bucket every 30 seconds. It computes HMAC-SHA256(secret_key, pass_id + time_bucket) and sets that value as the barcode on the pass. The pass is then pushed to the device via APNS with the new barcode value.

When a scanner reads the barcode, it sends the value to your server. The server recomputes HMAC-SHA256(secret_key, pass_id + current_time_bucket) — and also checks the previous time bucket to handle cases where the rotation happened mid-scan — and verifies the values match. If they do, the scan is valid. If the barcode is from a screenshot taken two minutes ago, it references a time bucket that has long since expired and the scan is rejected.

The secret key never leaves your server. Only your system can generate valid tokens. A screenshot shared by a customer is valid only for the duration of one rotation interval — not long enough to be useful in a venue queue.

Rotation interval: security vs APNS load

The rotation interval is a trade-off between security and server load. Shorter intervals are more secure but require more frequent APNS pushes and more frequent pass downloads.

30 seconds is appropriate for high-value event tickets where the fraud risk is significant. The customer's device receives a new pass update every 30 seconds while the pass is active. This is more APNS traffic than a standard pass update but is entirely within Apple's acceptable use parameters for a connected pass.

60 seconds suits loyalty cards and membership passes. The fraud risk for these use cases is lower — a shared screenshot of a loyalty card is annoying but not catastrophic — and a one-minute rotation keeps APNS traffic manageable across a large user base.

5 to 10 minutes works for passes that do not warrant the infrastructure overhead of sub-minute rotation but where some protection against screenshot sharing is still desirable. A pass used once per day at a gym could rotate every five minutes; the customer's screenshot would be invalid before they could reasonably share it with someone else during the same session.

NFC as an alternative to dynamic barcodes

NFC passes take a different approach to the same problem. Instead of making the barcode value time-sensitive, NFC passes require the customer's physical device to be present at the reader. There is no barcode to screenshot.

When a customer presents an NFC pass at a reader, the reader interrogates the device's Secure Element or the wallet app's NFC payload. The exchange happens over the contactless interface — the customer taps their phone to the reader, the reader validates the token and the gate opens. A screenshot provides nothing useful because the NFC exchange requires the hardware.

94% of smartphones in active use today have NFC. On iOS, Apple Wallet NFC passes use the NFC Data Exchange Format (NDEF) or Apple's proprietary Secure Element path. On Android, Google Wallet NFC passes use Host Card Emulation (HCE). Both approaches produce a tap-to-verify experience that is not susceptible to screenshot sharing.

The trade-off is reader hardware. NFC validation requires a compatible NFC reader at the access point — it cannot be performed with a standard smartphone camera. For venues with existing NFC gate infrastructure (gyms, offices, stadiums), this is not an obstacle. For a small retailer scanning passes with a phone camera, NFC requires a hardware investment.

When to use which approach

Dynamic QR codes are the right choice when your scanning infrastructure uses cameras (phones, tablet-based POS systems) and the pass value is high enough to justify the implementation cost. Use them for event tickets, high-value vouchers and premium membership cards.

NFC passes are the right choice when you have NFC reader hardware at the access point and need the strongest possible guarantee of physical presence. Use them for office access control, gym entry barriers and transport ticketing.

Static QR codes are acceptable for low-value use cases where the cost of fraud is negligible. A loyalty stamp card where each scan is worth 10% of a £4 coffee does not require cryptographic barcode rotation. A concert ticket worth £200 does.

Implementation considerations

Dynamic barcodes require three components that a static pass does not: a token generation function running on your server, a push endpoint that sends updated pass bundles on a schedule and a scanner app or backend that validates tokens rather than just looking up IDs.

The token generation function is straightforward to implement in any server-side language. HMAC-SHA256 is available in Node.js (crypto.createHmac), Python (hmac.new) and effectively every other runtime.

The push infrastructure is more involved. You need a scheduler that fires every N seconds, computes new tokens for all active passes and sends APNS updates. At large scale — tens of thousands of active passes — this requires a robust job queue to avoid missed rotations.

The scanner validation logic must accept the current time bucket and the previous one, to handle the case where a customer scanned in the last few seconds of a rotation window and the server is now in the next window. A two-window tolerance is standard.

Issuepass handles all of this natively. Dynamic barcode rotation is a configuration option on any pass template — choose your rotation interval, and we manage the token generation, the APNS push schedule and the validation endpoint. Your scanner calls our validation API with the scanned value and receives a pass/fail response with the customer's details.

Start free and enable dynamic barcodes on your first pass template today.