QR-Code zu Apple Wallet und Google Wallet: So funktionieren Kundenkarten, Tickets und Coupons wirklich

QR-Code zu Apple Wallet und Google Wallet: So funktionieren Kundenkarten, Tickets und Coupons wirklich

Wer "QR-Code Apple Wallet" bei Google eingibt, bekommt meist entweder eine oberflächliche Marketing-Anleitung, die den eigentlichen Mechanismus komplett ausspart, oder eine Entwickler-Dokumentationsseite, die voraussetzt, dass man bereits weiß, was ein Signaturzertifikat ist. Keine der beiden Varianten beantwortet die Frage, die eine Agentur tatsächlich hat: Ein Kunde möchte eine Kundenkarte, ein Ticket oder einen Coupon, den seine Kunden mit einem einzigen Scan auf dem Smartphone speichern können, und er möchte wissen, was dieser Scan technisch wirklich tut.

Die kurze Antwort: QR-Code und Wallet-Pass sind zwei verschiedene Objekte, die nur auf den ersten Blick zusammengehören. Ein QR-Code ist ein statisches Bild. Ein Wallet-Pass dagegen ist ein kleines signiertes Software-Bundle (bei iOS) oder ein cloudgehosteter Datensatz (bei Android), den das Betriebssystem des Smartphones als eigenständiges Objekt behandelt, komplett mit Icon auf dem Homescreen, Eintrag auf dem Sperrbildschirm und eigenem Update-Kanal. Die einzige Aufgabe des QR-Codes besteht darin, das Smartphone für einen einzigen Moment, den Moment des Speicherns, auf dieses Bundle oder diesen Datensatz zu verweisen. Danach führen Pass und Code ein getrenntes Leben.

Warum man ein QR-Code-Bild nicht einfach zu Apple Wallet "hinzufügen" kann

Genau dieser Teil wird in fast jeder Marketing-Anleitung übergangen. Man kann keine QR-Code-PNG-Datei per Drag-and-drop in Apple Wallet ziehen, so wie man ein Foto zur Kamerarolle hinzufügt. Apple Wallet akzeptiert grundsätzlich keine beliebigen Bilddateien.

Was Wallet stattdessen akzeptiert, ist eine .pkpass-Datei: ein signiertes ZIP-Archiv mit einem pass.json-Manifest, einem Icon und sämtlichen Bildern, die der Pass verwendet. Innerhalb von pass.json deklarieren Sie unter dem Schlüssel barcodes, welches Barcode-Format der Pass anzeigen soll und welche Daten darin codiert sind. Apples eigene Schema-Dokumentation legt das genau offen: Der Barcode ist ein Daten-Dictionary innerhalb des signierten Passes, keine Bilddatei, die in einen Ordner gelegt wird. Das gesamte Bundle wird kryptografisch mit einem Zertifikat signiert, das an Ihren Apple-Developer-Account gebunden ist, und Wallet verweigert die Installation, sobald die Signatur nicht passt.

Der tatsächliche Ablauf hinter "QR-Code zu Apple Wallet hinzufügen" sieht also so aus: serverseitig eine .pkpass-Datei erzeugen, die Barcode-Deklaration in deren pass.json einbetten, das Bundle signieren und an das Smartphone ausliefern (meist über einen "Zu Apple Wallet hinzufügen"-Button oder einen Link, den das Smartphone am MIME-Type erkennt und automatisch an Wallet übergibt). Ein bloßer QR-Code, der in einer QR-Scanner-App gescannt wird, hat in dieser Pipeline keinen Anknüpfungspunkt. Es gibt in Wallet keinen "Barcode importieren"-Button, weil Wallet nie dafür konzipiert wurde, einen entgegenzunehmen.

Das ist auch der Grund, warum so viele Agenturen am Ende das Falsche bauen: Ein QR-Code, der beim Scannen eine Seite mit einem weiteren QR-Code öffnet, ist kein Wallet-Pass. Der Kunde muss an der Kasse trotzdem noch etwas erneut scannen, was den ganzen Sinn eines gespeicherten Passes zunichtemacht.

Welche Barcode-Formate Apple Wallet tatsächlich unterstützt

Sobald ein Barcode korrekt innerhalb eines signierten Passes deklariert ist, unterstützt Apple Wallet ab iOS 9 laut Apples PKBarcodeFormat-Dokumentation genau vier Formate:

• PKBarcodeFormatQR - ein Standard-QR-Code, das flexibelste der vier Formate und dasjenige, das die meisten Kassenscanner ohne zusätzliche Hardware lesen können.
• PKBarcodeFormatPDF417 - das gestapelte lineare Format, das bei Bordkarten und manchen Ausweisdokumenten zum Einsatz kommt, weil es in einer breiten, flachen Form mehr Daten unterbringt, die auf einen Ticketabschnitt passt.
• PKBarcodeFormatAztec - kompakt und historisch bevorzugt von Verkehrsbetrieben und manchen Fluggesellschaften für schnelles Scannen am Gate.
• PKBarcodeFormatCode128 - ein klassischer 1D-Barcode, nützlich, wenn die Kassenhardware älteres POS-Equipment ist, das nur lineare Barcodes lesen kann.

Ein Pass kann jeweils nur ein deklariertes Format tragen (mit einem optionalen Legacy-Fallback für ältere iOS-Versionen), weshalb die Wahl wichtig ist. Für eine Kundenkarte im Einzelhandel oder einen Coupon ist QR fast immer die richtige Wahl: Es ist das Format, das der Scanner des Personals ohnehin erwartet, und dasjenige, das Kunden als "QR-Code" wiedererkennen, falls sie ihn einmal manuell vorzeigen müssen.

Warum das Modell von Google Wallet anders funktioniert

Google Wallet arbeitet überhaupt nicht mit signierten Datei-Bundles. Stattdessen basiert es auf einem Class-und-Object-Modell. Die Class ist eine Vorlage, die Sie einmal definieren, zum Beispiel "Acme Coffee Kundenkarte", mit Layout, Logo und Feldstruktur. Ein Object ist eine ausgestellte Instanz dieser Class, zum Beispiel die Kundenkarte, die einem bestimmten Kunden mit seinem individuellen Punktestand ausgestellt wird.

Damit jemand einen Pass hinzufügen kann, erzeugen Sie ein JWT (JSON Web Token), das auf Class und Object verweist, signieren es mit einem Service-Account-Schlüssel Ihres Google-Wallet-API-Issuer-Kontos und geben dem Kunden einen Link der Form https://pay.google.com/gp/v/save/<signed_jwt>. Tippt der Kunde auf diesen Link, oder scannt er einen QR-Code, der diesen Link codiert, teilt das den Servern von Google Wallet mit: "Hier ist eine signierte Anweisung, dieses konkrete Object der Wallet dieses Nutzers hinzuzufügen." Googles eigene JWT-Dokumentation beschreibt die genaue Struktur. Funktional übernimmt das dieselbe Rolle wie Apples signierte .pkpass-Datei, nur dass die Signierung gegen eine gehostete API erfolgt statt gegen ein Bundle, das Sie selbst erzeugen und ausliefern.

Dieser Unterschied ist bei der Projektplanung relevant: Eine Apple-Integration bedeutet, einen Dienst aufzusetzen, der Dateien erzeugt und signiert, während eine Google-Integration bedeutet, per API Class- und Object-Datensätze anzulegen und signierte Save-Links bei Bedarf zu generieren. Beide benötigen einen Signaturschlüssel, der serverseitig verwahrt wird, was ein weiterer Grund ist, warum ein einfacher QR-Code-Generator niemals von sich aus einen Wallet-Pass erzeugen kann.

Der Trick: ein Code für beide Plattformen

Und hier kommt der Teil, der für eine Agentur beim Kundenbriefing wirklich zählt: Sie brauchen keine zwei getrennten gedruckten QR-Codes für iOS- und Android-Nutzer. Das Standardmuster ist ein einzelner QR-Code, der auf eine kurze Redirect-URL verweist, die Ihr eigener Server kontrolliert, genau der gleiche Aufbau wie bei dynamischen und statischen QR-Codes in jeder anderen Kampagne. Scannt das Smartphone den Code und ruft diese URL auf, liest Ihr Server den User-Agent-Header aus, erkennt iOS oder Android und liefert die passende Antwort: einen .pkpass-Download für iPhone oder eine Weiterleitung zum signierten pay.google.com/gp/v/save/...-Link für Android.

Das sei klar gesagt: Das ist ein weit verbreitetes technisches Muster, keine offizielle Spezifikation von Apple oder Google. Keines der beiden Unternehmen dokumentiert einen gemeinsamen "Cross-Platform-Wallet-QR"-Standard, denn aus Sicht jeder einzelnen Plattform ist der QR-Code einfach nur ein QR-Code; die Weiche wird vollständig auf Ihrem Server gestellt, bevor überhaupt eine der beiden Wallet-Apps ins Spiel kommt. Es ist derselbe Trick, den Agenturen bereits nutzen, um einen QR-Code zu zwei App Stores zu schicken.

Weil die Verzweigungslogik auf Ihrem Server liegt, funktioniert das sauber nur mit einem dynamischen Code, dessen Ziel-URL Sie ändern können, ohne irgendetwas neu drucken zu müssen. Ein statischer Code, der direkt auf eine .pkpass-Datei oder einen einzelnen Save-Link zeigt, ist vom Tag des Drucks an auf eine Plattform festgelegt, und ein Kunde mit dem falschen Gerät bekommt schlicht eine Fehlermeldung.

Was sich wirklich aktualisiert: der Pass, nicht der Code

Der Teil, den die meisten Erklärartikel auslassen, ist genau der, der Wallet-Passes für eine Agentur wirklich nützlich macht: Sobald ein Kunde einen Pass gespeichert hat, ändert sich dessen gedruckter QR-Code nie wieder. Was sich ändert, ist der Inhalt, den die Server von Apple oder Google in den bereits gespeicherten Pass einspielen.

Bei Google Wallet erfolgt das Aktualisieren eines aktiven Passes, sei es das Ändern eines Punktestands, das Markieren eines Coupons als eingelöst oder das Ablaufenlassen eines Tickets nach der Veranstaltung, durch das Schreiben in die Felder des Objects über die API, und der gespeicherte Pass des Kunden aktualisiert sich automatisch, ohne dass erneut gescannt werden muss. Der Ablauf funktioniert nach demselben Prinzip: Googles Dokumentation zu abgelaufenen Kundenkarten zeigt, wie er programmatisch über object.validTimeInterval.end.date gesetzt wird, oder indem das Object in den Zustand Expired, Inactive oder Completed versetzt wird. Apple-Wallet-Updates funktionieren ähnlich, über einen Push-Benachrichtigungsmechanismus, der dem Smartphone mitteilt, dass sich ein Pass geändert hat und sein pass.json neu abgerufen werden soll.

Das ist der eigentliche Unterschied zwischen einem Wallet-Pass und einem QR-Code, der nur auf eine Webseite verlinkt, und genau dieser Punkt lohnt sich, einem Kunden zu vermitteln, der beide Varianten vergleicht. Das Ändern eines Ziels ohne Neudruck hält den gedruckten Code gleich, während sich die dahinterliegende Seite ändert. Ein Wallet-Pass geht einen Schritt weiter und hält auch das auf dem Smartphone des Kunden installierte Objekt aktuell, einschließlich Sperrbildschirm- und standortbasierter Einblendung, ganz ohne Zutun des Kunden.

Wo sich das wirklich auszahlt: Kundenkarten, Tickets, Coupons, Mitgliedskarten

Die vier praktischen Anwendungsfälle, die eine Agentur tatsächlich umsetzen wird, sind Kundenkarten, Event-Tickets, Coupons und Mitgliedskarten, und jeder stützt sich auf einen anderen Teil des Pass-Modells. Kundenkarten profitieren am meisten von dynamischen Feld-Updates, einem Punktestand oder einer Stufe, die sich ändert, ohne dass der Kunde irgendetwas erneut scannen muss. Event-Tickets hängen am stärksten von der Wahl des Barcode-Formats ab (PDF417 oder Aztec für schnelles Scannen am Einlass) und von standortbasierter Einblendung auf dem Sperrbildschirm in Veranstaltungsnähe. Coupons sind der einfachste Pass-Typ, ein einzelner Barcode und ein Ablaufdatum, profitieren aber am meisten von einem Server-Push "als eingelöst markieren" nach der Nutzung, damit ein abfotografierter Code nicht wiederverwendet werden kann. Mitgliedskarten kombinieren meist einen QR- oder Barcode mit einem Foto- oder Namensfeld zur Verifizierung durch das Personal, näher an einem Ausweis als an einem Treuestempel.

Google veröffentlicht namentlich benannte Partnerergebnisse für sein Wallet-Produkt, und gerade weil sie konkret zuordenbar sind statt vage Branchendurchschnitte, lohnt es sich, sie genau zu zitieren. Laut Googles veröffentlichten Wallet-Fallstudien: PizzaExpress Hong Kong berichtete von 5,5-fachem Mitgliederwachstum und 25 Prozent höheren Ausgaben pro Transaktion, nachdem das Treueprogramm auf Google Wallet umgestellt wurde; Xenos in den Niederlanden verzeichnete einen Anstieg der Treueprogramm-Anmeldungen um 80 Prozent; Salomon berichtete von einer 3-fachen Umsatzsteigerung und 54 Prozent mehr Artikeln pro Bestellung; und Kiehl's meldete eine Coupon-Einlösequote von 65 Prozent. Betrachten Sie diese Zahlen als Best-Case-Beispiele aus Googles eigenen Vorzeigepartnerschaften, nicht als Durchschnittswerte, die jede Kampagne erwarten sollte, aber sie sind ein deutlich ehrlicherer Bezugspunkt als die vagen "X % bevorzugen digitale Wallets"-Behauptungen, die ohne benannte Quelle kursieren.

Zur Einordnung der Größenordnung: Juniper Research schätzte, dass 2025 weltweit rund 4,4 Milliarden Menschen eine digitale Wallet nutzten, etwa 55 Prozent der Weltbevölkerung. Seien Sie präzise darin, was diese Zahl tatsächlich misst: Sie umfasst digitale Wallets und Zahlungs-Wallets im weiten Sinne (Apple Pay, Google Pay, PayPal und Ähnliches), nicht speziell Apple-Wallet- oder Google-Wallet-Passes wie Kundenkarten und Tickets. Sie sagt Ihnen, dass die adressierbare Zielgruppe bereits eine Wallet-App installiert hat und sie gewohnheitsmäßig nutzt, nicht, wie viele davon speziell Kundenkarten oder Tickets speichern.

Was die Einrichtung kostet und erfordert

Apple beschränkt das Erstellen und Signieren von Passes auf registrierte Entwickler. Vorausgesetzt wird eine Mitgliedschaft im Apple Developer Program, derzeit 99 US-Dollar pro Jahr, wobei für qualifizierte gemeinnützige, Bildungs- und Regierungsorganisationen Gebührenbefreiungen möglich sind. Diese Gebühr deckt den gesamten Entwickler-Account Ihrer Organisation ab, nicht eine Gebühr pro Pass oder pro Kampagne, sodass es für eine Agentur, die Passes für mehrere Kunden betreibt, eine einmalige Jahresgebühr ist und keine projektbezogene Abrechnungsposition.

Das "Add to Apple Wallet"-Badge selbst ist kostenlos nutzbar, aber Apple ist streng bei der Art der Nutzung: Es muss das unveränderte offizielle Asset in einer der von Apple definierten Lokalisierungen sein, mit dem vorgeschriebenen Freiraum platziert und mit dem erforderlichen Markenrechts-Hinweis angezeigt werden. Apples Richtlinienseite stellt ausdrücklich klar, dass Sie es weder umfärben noch außerhalb der Vorgaben skalieren noch durch ein eigenes Button-Design ersetzen dürfen und es dann trotzdem "Add to Apple Wallet"-Aktion nennen. Das bringt mehr Agenturen ins Straucheln, als es sollte: Ein individuell gestalteter, gebrandeter Button mag auf der Seite besser aussehen, ist aber nicht konform, wenn er nicht Apples Asset entspricht.

Google Wallet erfordert die Registrierung als Issuer über die Google Wallet API sowie die Einrichtung eines Service-Accounts und eines Signaturschlüssels für Ihre JWTs. Es gibt keine veröffentlichte pauschale Jahresgebühr wie bei Apple, aber der Aufbau und das Hosting der Class-/Object-Verwaltung sowie des Signaturdienstes ist trotzdem echte Entwicklungsarbeit und kein Plug-in.

Häufig gestellte Fragen

Kann man einen beliebigen QR-Code direkt zu Apple Wallet hinzufügen?

Nein. Apple Wallet installiert ausschließlich signierte .pkpass-Bundles. Ein QR-Code, der nicht in den barcodes-Daten eines Passes deklariert und in ein signiertes Bundle verpackt ist, hat keinen Weg in Wallet. Jeder Workflow, der behauptet, "einen QR-Code zu Apple Wallet hinzuzufügen", erzeugt und signiert im Hintergrund in Wirklichkeit eine .pkpass-Datei, die zufällig einen QR-Barcode enthält.

Wie bekommt man einen QR-Code in Google Wallet?

Sie definieren eine Class und ein Object für den Pass, erzeugen dann ein signiertes JWT, das darauf verweist, und geben dem Kunden einen Link der Form https://pay.google.com/gp/v/save/<jwt>, meist hinter einem QR-Code oder einem "Zu Google Wallet hinzufügen"-Button. Der Link, nicht ein rohes Bild, trägt die eigentliche Nutzlast des QR-Codes.

Was ist der Unterschied zwischen einem QR-Code und einem Wallet-Pass?

Ein QR-Code ist ein statisches Bild, das einen kurzen Datensatz codiert, meist eine URL. Ein Wallet-Pass ist eine signierte Datei (bei Apple) oder ein cloudgehosteter Datensatz (bei Google), der zu einem dauerhaften Objekt auf dem Smartphone des Kunden wird, mit eigenem Icon, Sperrbildschirm-Einblendung und Update-Kanal. Der QR-Code ist lediglich der Übertragungsmechanismus im Moment des Speicherns; der Pass ist das, was danach bestehen bleibt.

Laufen Wallet-Passes ab?

Ja, und beide Plattformen behandeln das als Zustand des Passes, nicht des Codes. Google Wallet setzt validTimeInterval.end.date eines Objects oder versetzt es in den Zustand Expired, Inactive oder Completed. Apple-Wallet-Passes tragen ein Feld expirationDate und können vom Server des Ausstellers zusätzlich für ungültig erklärt werden. So oder so setzen Sie den Ablauf auf dem Pass-Datensatz, nicht fest im gedruckten QR-Code.

Kann sich ein Wallet-Pass aktualisieren, ohne dass der Kunde erneut scannen muss?

Ja, das ist der Hauptvorteil gegenüber einem einfachen QR-Link. Sobald ein Pass gespeichert ist, kann der Server des Ausstellers aktualisierte Feldwerte pushen (einen neuen Punktestand, einen Eingelöst-Status, eine geänderte Sitzplatznummer), und das Smartphone aktualisiert den gespeicherten Pass automatisch, über Apples Push-Mechanismus oder Googles Object-API. Der Kunde muss dafür nie erneut scannen.

Welche Barcode-Formate unterstützt Apple Wallet?

Vier, ab iOS 9: QR (PKBarcodeFormatQR), PDF417, Aztec und Code128. QR ist mit Kassenscannern am breitesten kompatibel; PDF417 und Aztec sind bei Tickets und Bordkarten verbreitet; Code128 eignet sich für ältere, ausschließlich 1D-fähige POS-Hardware.

Braucht man einen Apple-Developer-Account, um Wallet-Passes zu erstellen?

Ja. Das Signieren eines .pkpass-Bundles erfordert ein Zertifikat, das an ein registriertes Mitglied des Apple Developer Program ausgestellt wird, derzeit 99 US-Dollar pro Jahr, mit Befreiungen für qualifizierte gemeinnützige Organisationen, Schulen und Behörden. Außerhalb dieses Programms gibt es keine Möglichkeit, einen gültigen Pass zu signieren.

Kann ein QR-Code sowohl für Apple Wallet als auch für Google Wallet funktionieren?

Ja, aber nur indirekt. Der gedruckte Code verweist auf eine Redirect-URL auf Ihrem eigenen Server. Dieser Server erkennt anhand des User-Agent-Headers, ob das scannende Gerät iOS oder Android ist, und liefert den passenden Ablauf aus, einen .pkpass-Download oder einen signierten Google-Save-Link. Diese geräteerkennende Weiterleitung ist ein gängiges technisches Muster, keine nativ eingebaute Funktion einer der beiden Plattformen, und sie setzt voraus, dass der Code dynamisch ist statt ein statischer Link auf die Datei einer einzelnen Plattform.

Wie fügt man eine QR-Code-Kundenkarte ohne eigene App hinzu?

Genau das löst ein Wallet-Pass: Keine der beiden Plattformen verlangt vom Unternehmen eine eigene App. Die Kundenkarte lebt innerhalb der bereits vorhandenen Wallet-App des Kunden, hinzugefügt über den oben beschriebenen .pkpass/JWT-Ablauf, sodass "keine App nötig" für den Kunden zutrifft, auch wenn im Hintergrund trotzdem jemand den passausstellenden Dienst bauen muss.

Ist das "Add to Apple Wallet"-Badge kostenlos nutzbar?

Ja, das Badge-Asset selbst ist gebührenfrei, muss aber laut Apples offiziellen Richtlinien unverändert, in einer freigegebenen Lokalisierung, mit dem vorgeschriebenen Mindestfreiraum und dem erforderlichen Markenrechts-Hinweis verwendet werden. Das Grafikmaterial zu verändern oder durch einen eigenen Button zu ersetzen und es trotzdem "Add to Apple Wallet" zu nennen, ist nicht konform.

Können Wallet-Passes Push- oder Standortbenachrichtigungen senden?

Ja, innerhalb der von jeder Plattform gesetzten Grenzen. Ein Pass kann auf dem Sperrbildschirm erscheinen, wenn sich der Kunde in der Nähe eines relevanten Standorts befindet (ein Coupon in Ladennähe, ein Ticket in Veranstaltungsnähe), und Aussteller können Inhalts-Updates pushen, die als Pass-Änderungen erscheinen. Das ist ein echter Funktionsunterschied zu einem QR-Code, der auf eine statische Webseite verlinkt, welcher zwischen den Scans keine vergleichbare Präsenz auf dem Gerät hat.

Die Kurzfassung

Ein bloßer QR-Code kann nicht in Apple Wallet gelangen: Er muss in den barcodes-Daten eines signierten .pkpass-Bundles deklariert werden, in einem von genau vier unterstützten Formaten (QR, PDF417, Aztec, Code128). Google Wallet funktioniert wiederum anders, aufgebaut auf einem Class-/Object-Modell, das über einen signierten JWT-Save-Link statt über ein Datei-Bundle hinzugefügt wird. Ein einziger gedruckter QR-Code kann trotzdem beide Plattformen bedienen, indem er auf Ihren eigenen Redirect-Server verweist, der iOS von Android unterscheidet und den passenden Ablauf ausliefert, dasselbe Muster des dynamischen Codes, das auch beim Routing zu zwei App Stores verwendet wird. Sobald ein Pass gespeichert ist, ist es der Inhalt des Passes, nicht der gedruckte Code, der sich aktualisiert: Punktestände, Einlösestatus und Ablaufdatum leben allesamt serverseitig. Wenn Sie einen Kunden zu Kundenkarten, Tickets oder Coupons briefen, entscheiden Sie zunächst, ob Sie tatsächlich die Persistenz und Sperrbildschirm-Einblendung brauchen, die ein Wallet-Pass bietet, oder ob ein gut gebauter QR-Code-Retargeting-Ablauf auf eine normale Landingpage das Problem einfacher löst. Und falls die Kampagne Wallets Installationsschritt überhaupt nicht braucht, lohnt sich ein Vergleich mit NFC-Tags, bevor Sie sich für eine der beiden Optionen entscheiden.