Wallet Pass GDPR Compliance: What Personal Data You Store and How to Handle It

A wallet pass sits on a customer's device and displays information about them — their name, their membership number, sometimes their date of birth or insurance policy reference. That information is personal data under the General Data Protection Regulation, and the rules that govern how you collect, store and delete it apply just as much to a digital loyalty card as they do to an email list or a CRM record. If your business issues wallet passes to customers in the United Kingdom or European Union, you need to understand your GDPR obligations clearly before you go live.

What personal data is embedded in a wallet pass

The fields you can populate in a wallet pass vary by pass type, but most issued passes contain at least some of the following:

• Full name. Displayed on loyalty cards, membership cards and event tickets to personalise the pass and confirm ownership.
• Email address. Often stored in the back fields or used as the unique identifier for pass lookup on your server.
• Member number or account reference. A unique identifier that links the pass to a record in your CRM or loyalty platform.
• Date of birth. Common on age-verified membership cards (gyms, clubs, licensed venues) or health-related passes.
• Health insurance number or policy reference. Present on digital insurance cards and health membership passes.
• Points balance or tier status. Not itself directly identifying, but tied inseparably to the named individual whose pass it is.

All of the above constitute personal data under Article 4 of the GDPR. The name and email address are clearly identifiable; the member number is identifiable by reference to your records. The moment any of this data is processed — collected, stored, transmitted, displayed — GDPR applies.

Establishing a lawful basis for processing

You must have a lawful basis under Article 6 of the GDPR before you process any personal data in a wallet pass. Two bases are most commonly applicable.

Contractual necessity (Article 6(1)(b)). If the pass is issued as part of a service the customer signed up for — a loyalty programme, a gym membership, an event ticket — processing their name and member number to render that pass is necessary for performing the contract. You do not need separate consent for this processing. The customer enrolled in the loyalty programme; issuing the digital card is an inherent part of fulfilling that enrolment.

Consent (Article 6(1)(a)). If the pass is issued for marketing purposes — such as a coupon or promotional card — and the customer has not entered into a service contract with you, you will likely need explicit consent. Obtain this at the point of sign-up with a clear opt-in, and record when and how consent was given.

Whichever basis you rely on, document it in your Record of Processing Activities (ROPA) alongside the purpose, data categories and retention period.

The data minimisation principle

Article 5(1)(c) of the GDPR requires that personal data be “adequate, relevant and limited to what is necessary.” Applied to wallet passes, this means you should only embed fields that the pass genuinely needs to fulfil its purpose.

A coffee shop stamp card needs a name and a stamp count — nothing else. It does not need the customer's date of birth, postal address or email address embedded in the visible fields. A gym membership card needs a name, member number and expiry date. It does not need the member's health conditions or payment history.

Before finalising your pass template, audit every field and ask: does removing this field make the pass unable to fulfil its purpose? If the answer is no, remove it. Back fields can store additional reference data for operational use, but apply the same discipline there too.

Where pass data lives — and who is responsible for it

When a customer adds a pass to their wallet, the pass bundle (a signed file containing all the displayed data) is stored on their device. Apple Wallet and Google Wallet render the pass from that local file. Neither Apple nor Google independently process the personal data beyond what is needed to display the pass and deliver update notifications.

Your pass server — the system that generates, updates and revokes passes — holds a copy of every pass record, including all personal data embedded in it. That server is the primary location of your GDPR obligations. You are the data controller; your pass platform is the data processor.

You also hold push registration tokens — device identifiers that allow you to send notifications to specific passes. These tokens are personal data by virtue of being linked to identified individuals. They must be treated with the same care as the pass data itself.

Subject access and the right to erasure

Two rights under the GDPR are particularly relevant to wallet passes: the right of access (Article 15) and the right to erasure (Article 17).

If a customer submits a Subject Access Request, you must be able to provide all personal data you hold about them, including the data embedded in their wallet pass, the push token, and any historical pass update records. Ensure your pass platform exposes this data in a machine-readable format.

If a customer exercises their right to erasure, the response involves more than deleting a database row. You must:

1. Revoke the pass — making it non-functional and showing it as expired or voided on the device.
2. Delete the associated personal data from your pass server records.
3. Delete the push registration token so no future notifications can be sent.
4. Remove the pass record from any backups within your defined backup retention window.

Note that revoking a pass does not delete the pass file from the customer's device — that requires the customer to manually remove it from their wallet. Inform the customer of this in your erasure confirmation.

Data retention policy

You must define a retention period for pass data and document it in your privacy policy. A typical retention policy for loyalty pass data reads: “We retain wallet pass data for 24 months following the date of last activity (last scan, last point redemption or last pass update). After this period, pass records are automatically purged from our systems and the pass is revoked.”

Set up automated deletion workflows in your pass platform to enforce the retention period. Manual deletion is error-prone at scale and will not survive a GDPR audit.

Your pass platform as a data processor

Under the GDPR, any third-party service that processes personal data on your behalf is a data processor. Your wallet pass platform — the service that stores pass records, generates pass bundles and handles push delivery — is a data processor.

Article 28 of the GDPR requires you to have a written Data Processing Agreement (DPA) with every data processor. This agreement must specify what data is processed, for what purpose, the security measures in place, and the processor's obligations regarding sub-processors, deletion and audit rights.

Issuepass provides a DPA for all customers and offers EU data residency — your pass data is stored and processed within EU infrastructure, avoiding the cross-border transfer complications that arise when data leaves the EEA. We also support the right to erasure workflows described above, with a single API call to revoke a pass and delete all associated personal data from our servers.

If you are issuing wallet passes to EU or UK customers and want a platform built with GDPR compliance as a first-class concern, Start free and review our DPA before your first pass goes live.