QR-code toevoegen aan Apple Wallet en Google Wallet: zo werken loyaliteitskaarten, tickets en coupons echt

QR-code toevoegen aan Apple Wallet en Google Wallet: zo werken loyaliteitskaarten, tickets en coupons echt

Typ "QR-code Apple Wallet" in Google en het meeste dat naar boven komt is óf een dun marketing-stappenplan dat het hele mechanisme overslaat, óf een developer-docs pagina die ervan uitgaat dat je al weet wat een signing certificate is. Geen van beide beantwoordt de vraag die een bureau echt heeft: een klant wil een loyaliteitskaart, een ticket of een coupon die klanten met één scan op hun telefoon kunnen opslaan, en ze willen weten wat die scan daadwerkelijk doet.

Het korte antwoord is dat de QR-code en de wallet-pass twee verschillende objecten zijn die alleen met elkaar verbonden lijken. Een QR-code is een statische afbeelding. Een wallet-pass is een klein, ondertekend softwarepakket (op iOS) of een in de cloud gehost record (op Android) dat het besturingssysteem van de telefoon als een volwaardig object behandelt, compleet met een icoon op het beginscherm, een vermelding op het vergrendelscherm en een eigen updatekanaal. De enige taak van de QR-code is om de telefoon op het moment van opslaan even naar dat pakket of record te wijzen. Daarna leiden de pass en de code hun eigen leven.

Waarom je een QR-code-afbeelding niet zomaar kunt "toevoegen" aan Apple Wallet

Dit is het onderdeel dat bijna elke marketinggids overslaat. Je kunt geen QR-code PNG naar Apple Wallet slepen zoals je een foto aan je camerarol toevoegt. Apple Wallet accepteert helemaal geen willekeurige afbeeldingen.

Wat het wel accepteert is een .pkpass-bestand: een ondertekend zip-archief met een pass.json-manifest, een icoon en eventuele afbeeldingen die de pass gebruikt. In pass.json declareer je onder een barcodes-sleutel welk barcodeformaat de pass moet tonen en welke data daarin gecodeerd zit. Apple's eigen schemadocumentatie legt dit uit: de barcode is een datadictionary binnen de ondertekende pass, geen afbeeldingsbestand dat in een map wordt gezet. Het hele pakket is cryptografisch ondertekend met een certificaat dat aan jouw Apple Developer-account gekoppeld is, en Wallet weigert alles te installeren waarvan de handtekening niet klopt.

De werkelijke flow voor "een QR-code toevoegen aan Apple Wallet" is dus: server-side een .pkpass-bestand genereren, de barcodedeclaratie in het pass.json-bestand opnemen, het pakket ondertekenen en aan de telefoon aanbieden (meestal achter een "Add to Apple Wallet"-knop, of een link die de telefoon aan het MIME-type herkent en automatisch aan Wallet doorgeeft). Een kale QR-code die in een QR-scannerapp wordt gescand, kan nergens in die pipeline terecht. Er is geen "barcode importeren"-knop in Wallet, omdat Wallet daar nooit voor is ontworpen.

Dit is ook waarom zoveel bureaus uiteindelijk het verkeerde ding bouwen: een QR-code die, wanneer gescand, een pagina opent met nog een QR-code, is geen wallet-pass. De klant moet dan bij de kassa alsnog iets opnieuw scannen, wat het hele punt van het opslaan van een pass tenietdoet.

Welke barcodeformaten Apple Wallet daadwerkelijk ondersteunt

Zodra een barcode correct is gedeclareerd binnen een ondertekende pass, ondersteunt Apple Wallet op iOS 9 en later precies vier formaten, volgens Apple's PKBarcodeFormat-documentatie:

• PKBarcodeFormatQR - een standaard QR-code, de meest flexibele van de vier en degene die de meeste kassascanners zonder extra hardware kunnen lezen.
• PKBarcodeFormatPDF417 - het gestapelde lineaire formaat dat wordt gebruikt op instapkaarten en sommige identiteitsdocumenten, gekozen omdat het meer data kwijt kan in een brede, korte vorm die op een ticketstrookje past.
• PKBarcodeFormatAztec - compact en van oudsher favoriet bij vervoersbedrijven en sommige luchtvaartmaatschappijen voor snelle gate-scans.
• PKBarcodeFormatCode128 - een traditionele 1D-barcode, nuttig wanneer de kassahardware oudere POS-apparatuur is die alleen lineaire barcodes leest.

Een pass kan maar één gedeclareerd formaat tegelijk dragen (met een optionele legacy-fallback voor oudere iOS-versies), dus de keuze is belangrijk. Voor een loyaliteitskaart of coupon in de retail is QR bijna altijd de juiste keuze: het is wat de scanner van je personeel al verwacht, en het is wat mensen herkennen als "een QR-code" als ze hem ooit handmatig moeten tonen.

Hoe het model van Google Wallet verschilt

Google Wallet gebruikt helemaal geen ondertekende bestandspakketten. In plaats daarvan werkt het volgens een Class-en-Object-model. De Class is een template die je één keer definieert, bijvoorbeeld "Acme Coffee Loyalty Card", met de layout, het logo en de veldstructuur. Een Object is één uitgegeven instantie van die Class, bijvoorbeeld de loyaliteitskaart die aan een specifieke klant is uitgegeven met diens specifieke puntensaldo.

Om iemand een pass te laten toevoegen, genereer je een JWT (JSON Web Token) dat naar de Class en het Object verwijst, onderteken je die met een service-accountsleutel van je Google Wallet API Issuer-account, en geef je de klant een link in de vorm https://pay.google.com/gp/v/save/<signed_jwt>. Door op die link te tikken, of door een QR-code te scannen die deze link codeert, geeft dat de servers van Google Wallet de instructie: "hier is een ondertekende opdracht om dit specifieke object aan de wallet van deze gebruiker toe te voegen." Google's eigen JWT-documentatie beschrijft de exacte structuur. Functioneel speelt dit dezelfde rol als Apple's ondertekende .pkpass, maar het ondertekenen gebeurt via een gehoste API in plaats van een pakket dat je zelf genereert en aanbiedt.

Dit onderscheid is belangrijk bij het inschatten van een project: een Apple-integratie betekent dat je een service opzet die bestanden genereert en ondertekent, terwijl een Google-integratie betekent dat je een API aanroept om Class- en Object-records aan te maken en op aanvraag ondertekende save-links te genereren. Beide hebben een signing key nodig die server-side blijft, wat nog een reden is waarom een gewone QR-codegenerator nooit op zichzelf een wallet-pass kan produceren.

Eén QR-code voor twee platforms: de truc

Dit is het deel dat er echt toe doet wanneer een bureau een klant briefed: je hebt geen twee aparte gedrukte QR-codes nodig voor iOS- en Android-gebruikers. Het standaardpatroon is één QR-code die naar een korte redirect-URL wijst die je eigen server beheert, dezelfde opzet die je zou gebruiken voor dynamische versus statische QR-codes bij elke andere campagne. Wanneer de telefoon de code scant en die URL bereikt, leest jouw server de User-Agent-header, detecteert iOS of Android, en geeft de bijpassende respons: een .pkpass-download voor iPhone, of een redirect naar de ondertekende pay.google.com/gp/v/save/...-link voor Android.

Om het maar even helder te stellen: dit is een veelgebruikt engineeringpatroon, geen formele Apple- of Google-specificatie. Geen van beide bedrijven documenteert een gezamenlijke "cross-platform wallet-QR"-standaard, want vanuit het perspectief van elk platform is de QR-code gewoon een QR-code; de vertakking gebeurt volledig op jouw server voordat een van beide Wallet-apps in beeld komt. Het is dezelfde truc die bureaus al gebruiken om één QR-code naar twee appstores te sturen.

Omdat de vertakkingslogica op jouw server draait, werkt dit alleen goed met een dynamische code, een code waarvan je de doel-URL kunt aanpassen zonder iets opnieuw te hoeven drukken. Een statische code die rechtstreeks naar een .pkpass-bestand of één save-link verwijst, ligt vanaf de dag dat hij gedrukt wordt vast op één platform, en een klant met het verkeerde toestel krijgt gewoon een foutmelding.

Wat er echt verandert: de pass, niet de code

Het onderdeel dat de meeste uitlegcontent overslaat, is precies wat wallet-passes echt nuttig maakt voor een bureau: nadat een klant een pass heeft opgeslagen, verandert de gedrukte QR-code nooit meer. Wat wél verandert, is de inhoud die de servers van Apple of Google naar die al opgeslagen pass pushen.

Op Google Wallet gebeurt het bijwerken van een live pass (een loyaliteitspuntensaldo aanpassen, een coupon als verzilverd markeren, een ticket na afloop van het evenement laten verlopen) door de velden van het Object via de API te beschrijven, en de opgeslagen pass van de klant ververst zich automatisch, zonder dat er opnieuw gescand hoeft te worden. Verlopen werkt op dezelfde manier: Google's documentatie over verlopen loyaliteitspasses laat zien dat dit programmatisch wordt ingesteld via object.validTimeInterval.end.date, of door het object naar een Expired-, Inactive- of Completed-status te verplaatsen. Updates in Apple Wallet werken op vergelijkbare wijze, via een pushmeldingsmechanisme dat de telefoon laat weten dat een pass is gewijzigd en dat hij zijn pass.json opnieuw moet ophalen.

Dit is het echte verschil tussen een wallet-pass en een QR-code die simpelweg naar een webpagina linkt, en dit is het punt dat de moeite waard is om te maken naar een klant die de twee vergelijkt. Een bestemming wijzigen zonder opnieuw te drukken houdt de gedrukte code hetzelfde terwijl de pagina erachter verandert. Een wallet-pass gaat een stap verder en houdt ook het geïnstalleerde object op de telefoon van de klant actueel, inclusief weergave op het vergrendelscherm en op basis van locatie, zonder dat de klant ook maar iets hoeft te doen.

Waar dit zich terugbetaalt: loyaliteit, tickets, coupons, lidmaatschap

De vier praktische use cases die een bureau daadwerkelijk zal bouwen zijn loyaliteitskaarten, evenemententickets, coupons en lidmaatschapskaarten, en elk leunt op een ander onderdeel van het pass-model. Loyaliteitskaarten halen de meeste waarde uit dynamische veldupdates, een puntensaldo of niveau dat verandert zonder dat de klant iets opnieuw hoeft te scannen. Evenemententickets leunen het zwaarst op de keuze van het barcodeformaat (PDF417 of Aztec voor snelle gate-scans) en op locatiegebaseerde weergave op het vergrendelscherm in de buurt van de locatie. Coupons zijn het eenvoudigste pass-type, één barcode en een vervaldatum, maar profiteren het meest van een "markeer als verzilverd"-push vanaf de server zodra hij gebruikt is, zodat een geschermafbeelde code niet opnieuw kan worden gebruikt. Lidmaatschapskaarten combineren doorgaans een QR- of barcode met een foto of naamveld voor verificatie door personeel, en lijken daarmee meer op een identiteitskaart dan op een spaarkaart.

Google publiceert naamgebonden partnerresultaten voor zijn Wallet-product, en die zijn het citeren waard, juist omdat ze herleidbaar zijn in plaats van generieke branchegemiddelden. Volgens Google's gepubliceerde Wallet-casestudy's: PizzaExpress Hong Kong rapporteerde 5,5x groei in lidmaatschappen en 25 procent hogere besteding per transactie na de overstap van loyaliteit naar Google Wallet; Xenos in Nederland zag een stijging van 80 procent in loyaliteitsregistraties; Salomon rapporteerde een 3x omzetstijging en 54 procent meer artikelen per bestelling; en Kiehl's rapporteerde een verzilveringspercentage van 65 procent voor coupons. Beschouw dit als best-case voorbeelden van Google's eigen uitgelichte partners, niet als een gemiddelde dat elke campagne mag verwachten, maar het is een veel eerlijker referentiepunt dan de vage "X% geeft de voorkeur aan digitale wallets"-claims die zonder genoemde bron rondgaan.

Voor context over de schaal: Juniper Research schatte dat wereldwijd zo'n 4,4 miljard mensen in 2025 een digitale wallet gebruikten, ongeveer 55 procent van de wereldbevolking. Wees precies over wat dat cijfer meet: het gaat breed over digitale en betaalwallets (Apple Pay, Google Pay, PayPal en vergelijkbare diensten), niet specifiek over Apple Wallet- of Google Wallet-passes zoals loyaliteitskaarten en tickets. Het vertelt je dat de bereikbare doelgroep al een wallet-app heeft geïnstalleerd en die gewoontegetrouw gebruikt, niet hoeveel van hen specifiek loyaliteitskaarten of tickets opslaan.

Wat het kost en vergt om op te zetten

Apple beperkt het aanmaken en ondertekenen van passes tot aangesloten developers. Dat vereist lidmaatschap van het Apple Developer Program, momenteel $99 per jaar, met vrijstellingen voor in aanmerking komende non-profit-, onderwijs- en overheidsorganisaties. Die vergoeding dekt het hele developeraccount van je organisatie, geen kosten per pass of per campagne, dus voor een bureau dat passes voor meerdere klanten runt, is het een eenmalige jaarlijkse kostenpost in plaats van iets dat je per project doorberekent.

De "Add to Apple Wallet"-badge zelf is gratis te gebruiken, maar Apple is streng over hoe: het moet het ongewijzigde officiële asset zijn in een van Apple's vastgelegde lokalisaties, geplaatst met de voorgeschreven vrije ruimte eromheen, en getoond met de vereiste vermelding van het handelsmerk. Apple's richtlijnenpagina is expliciet dat je het niet mag herkleuren, buiten de specificaties mag vergroten of verkleinen, of vervangen door je eigen knopontwerp en het toch een "Add to Apple Wallet"-actie mag noemen. Meer bureaus dan nodig lopen hierover te struikelen: een knop op maat met eigen huisstijl oogt misschien beter op de pagina, maar als hij niet overeenkomt met Apple's asset, voldoet hij niet.

Voor Google Wallet moet je je registreren als issuer via de Google Wallet API, en een service account en een signing key voor je JWT's opzetten. Er is geen gepubliceerde vaste jaarlijkse vergoeding zoals bij Apple, maar het bouwen en hosten van het Class/Object-beheer en de signing-service is nog steeds echt engineeringwerk, geen kant-en-klare plug-in.

Veelgestelde vragen

Kun je zomaar een QR-code toevoegen aan Apple Wallet?

Nee. Apple Wallet installeert alleen ondertekende .pkpass-pakketten. Een QR-code die niet is gedeclareerd binnen de barcodes-data van een pass en verpakt in een ondertekend pakket, heeft geen route naar Wallet. Elke workflow die beweert "een QR-code toe te voegen aan Apple Wallet" genereert en ondertekent onder de motorkap gewoon een .pkpass-bestand dat toevallig een QR-barcode bevat.

Hoe zet je een QR-code in Google Wallet?

Je definieert een Class en een Object voor de pass, genereert vervolgens een ondertekende JWT die daarnaar verwijst en geeft de klant een https://pay.google.com/gp/v/save/<jwt>-link, meestal achter een QR-code of een "Add to Google Wallet"-knop. De link, niet een losse afbeelding, draagt de daadwerkelijke payload van de QR-code.

Wat is het verschil tussen een QR-code en een wallet-pass?

Een QR-code is een statische afbeelding die een klein stukje data codeert, meestal een URL. Een wallet-pass is een ondertekend bestand (Apple) of een in de cloud gehost record (Google) dat een blijvend object op de telefoon van de klant wordt, met een eigen icoon, weergave op het vergrendelscherm en een updatekanaal. De QR-code is alleen het afleveringsmechanisme op het moment van opslaan; de pass is het ding dat daarna blijft bestaan.

Kunnen wallet-passes verlopen?

Ja, en beide platforms behandelen dit als pass-status, niet als code-status. Google Wallet stelt de validTimeInterval.end.date van een object in, of verplaatst het naar een Expired-, Inactive- of Completed-status. Apple Wallet-passes hebben een expirationDate-veld en kunnen ook door de server van de uitgever ongeldig worden gemaakt. Hoe dan ook, het verlopen stel je in op het pass-record, niet iets dat vastgebakken zit in de gedrukte QR-code.

Kan een wallet-pass updaten zonder dat de klant opnieuw scant?

Ja, dit is het belangrijkste voordeel ten opzichte van een gewone QR-link. Zodra een pass is opgeslagen, kan de server van de uitgever bijgewerkte veldwaarden pushen (een nieuw puntensaldo, een verzilverde status, een gewijzigd stoelnummer) en ververst de telefoon de opgeslagen pass automatisch, via Apple's pushmechanisme of Google's Object API. De klant hoeft nooit iets opnieuw te scannen.

Welke barcodeformaten ondersteunt Apple Wallet?

Vier, vanaf iOS 9 en later: QR (PKBarcodeFormatQR), PDF417, Aztec en Code128. QR is het breedst compatibel met retailscanners; PDF417 en Aztec komen veel voor bij tickets en instapkaarten; Code128 past bij oudere POS-hardware die alleen 1D leest.

Heb je een Apple Developer-account nodig om Wallet-passes te maken?

Ja. Voor het ondertekenen van een .pkpass-pakket is een certificaat nodig dat is uitgegeven aan een aangesloten lid van het Apple Developer Program, momenteel $99 per jaar, met vrijstellingen voor in aanmerking komende non-profits, scholen en overheidsinstanties. Er is geen manier om een geldige pass te ondertekenen buiten dat programma om.

Kan één QR-code werken voor zowel Apple Wallet als Google Wallet?

Ja, maar alleen indirect. De gedrukte code wijst naar een redirect-URL op je eigen server. Die server detecteert via de User-Agent-header of het scannende toestel iOS of Android is en levert de bijpassende flow: een .pkpass-download of een ondertekende Google-save-link. Deze redirect op basis van toestelherkenning is een veelgebruikt engineeringpatroon, geen functie die een van beide platforms native inbouwt, en het hangt ervan af dat de code dynamisch is in plaats van een statische link naar het bestand van één platform.

Hoe voeg je een QR-code-loyaliteitskaart toe zonder app?

Dit is precies wat een wallet-pass oplost: geen van beide platforms vereist dat het bedrijf een eigen app bouwt. De loyaliteitskaart leeft in de bestaande Wallet-app van de klant, toegevoegd via de hierboven beschreven .pkpass/JWT-flow, dus "geen app nodig" klopt voor de klant, ook al moet er achter de schermen nog steeds iemand de pass-uitgevende service bouwen.

Is de "Add to Apple Wallet"-badge gratis te gebruiken?

Ja, het badge-asset zelf brengt geen licentiekosten met zich mee, maar het moet ongewijzigd worden gebruikt, in een goedgekeurde lokalisatie, met de voorgeschreven minimale vrije ruimte en de vereiste vermelding van het handelsmerk, volgens Apple's officiële richtlijnen. Het aanpassen van het ontwerp of het vervangen door een eigen knop en het toch "Add to Apple Wallet" noemen, voldoet niet aan de regels.

Kunnen wallet-passes push- of locatiemeldingen versturen?

Ja, binnen de grenzen die elk platform stelt. Een pass kan op het vergrendelscherm verschijnen wanneer de klant in de buurt van een relevante locatie is (een coupon bij een winkel, een ticket bij een evenementenlocatie), en uitgevers kunnen content-updates pushen die als pass-wijzigingen verschijnen. Dat is een echt verschil in mogelijkheden ten opzichte van een QR-code die naar een statische webpagina linkt, die tussen scans door geen enkele vergelijkbare aanwezigheid op het toestel heeft.

De korte versie

Een kale QR-code kan niet zomaar in Apple Wallet: hij moet gedeclareerd zijn binnen de barcodes-data van een ondertekend .pkpass-pakket, in een van precies vier ondersteunde formaten (QR, PDF417, Aztec, Code128). Google Wallet werkt weer anders, gebouwd op een Class/Object-model dat wordt toegevoegd via een ondertekende JWT-save-link in plaats van een bestandspakket. Eén gedrukte QR-code kan nog steeds beide platforms bedienen door naar je eigen redirect-server te wijzen, die iOS versus Android detecteert en de juiste flow levert, hetzelfde dynamische-code-patroon dat wordt gebruikt om naar twee appstores te routeren. Zodra een pass is opgeslagen, is het de inhoud van de pass, niet de gedrukte code, die wordt bijgewerkt: puntensaldi, verzilveringsstatus en het verlopen leven allemaal aan de serverkant. Als je een klant briefed over loyaliteitskaarten, tickets of coupons, bepaal dan eerst of je echt de persistentie en weergave op het vergrendelscherm nodig hebt die een wallet-pass biedt, of dat een goed gebouwde QR-code-retargeting-flow naar een normale landingspagina het probleem eenvoudiger oplost. En als de campagne de installatiestap van Wallet helemaal niet nodig heeft, is het de moeite waard om te vergelijken met NFC-tags voordat je je aan een van beide vastlegt.