Add Your Digital Business Card to Apple Wallet & Google Wallet (2026 Step-by-Step Guide)

Last reviewed: April 2026 · Word count: ~3,100 · Author: Ahmad Tayyem, founder of QRLynx · External sources: Apple Developer Documentation, Google Wallet Developer Documentation, RFC 6350 (vCard 3.0), ISO/IEC 7816-4

Hand someone a paper business card and you're betting on three things in sequence: they don't lose it, they remember to type your contact details into their phone, and they actually do it before the card slides into a desk drawer for six months. The dropout rate at each step is documented and ugly — research shows nearly 88% of paper business cards are discarded within a week.

A vCard QR code (the kind you can generate at qrlynx.com/vcard-contact-qr-code) collapses two of those steps. Scan, tap "Add to Contacts," done. But the contact lives in their address book — surfaced only when they remember your name and search for it. The recipient still has to know they have your card.

An Apple Wallet or Google Wallet pass solves the third problem: discoverability after the fact. Saved passes live next to boarding passes, loyalty cards, payment cards. The phone surfaces them on the lock screen when relevant (location-based on Apple Wallet, time-based on Google Wallet). Your card has the same retention dynamics as their gym membership and their plane ticket — durable, glanceable, organized.

And the share flow itself takes one tap on the recipient's phone. No app install, no account creation, no email signup, no friction. QRLynx Digital Business Cards ship both Apple Wallet and Google Wallet save buttons on every plan including free, so this is the actual share flow we recommend in 2026.

Apple and Google built different systems with different formats. Knowing the difference helps explain why a pass works on one platform and not the other, and why the file you download is shaped the way it is.

Apple PassKit (.pkpass)

An Apple Wallet pass is a ZIP file with the extension .pkpass and the MIME type application/vnd.apple.pkpass. Inside the ZIP:

• pass.json — the structured pass content (name, title, company, fields, colors, barcode payload)
• manifest.json — a dictionary mapping each filename in the ZIP to its SHA-1 hash
• signature — a PKCS#7 detached signature of manifest.json made with the issuer's Pass Type ID certificate, signed against Apple's Worldwide Developer Relations (WWDR) intermediate cert
• icon.png, icon@2x.png, icon@3x.png — required logo at three pixel densities
• Optional: thumbnail.png, strip.png, background.png — image elements for the front of the pass

When iPhone Safari (or Mail, or Messages) sees a response with that MIME type, it intercepts the download and triggers the Wallet "Add Pass" preview UI. The user sees the front of the pass, taps Add, and it lands in their Wallet app. The OS verifies the PKCS#7 signature chain against the bundled WWDR intermediate before saving — if signing is invalid, the pass is rejected with no helpful error.

Google Wallet Generic Pass

Google takes a different approach. There's no file format you ship to the user; instead, you build a pass object server-side and emit a URL like https://pay.google.com/gp/v/save/<JWT> where the JWT (RS256-signed by your service account) contains the full pass content as a payload. When the user taps the URL on Android (or desktop), Google parses the JWT, validates the signature against your registered service account, and saves the pass to the user's Google Wallet on their account — no file download, no MIME type negotiation.

Google also requires a "Pass Class" registered ahead of time in the Pay & Wallet Console — this is the template (issuer name, default colors, logo) that every pass instance references. Apple has no equivalent class abstraction; every .pkpass is fully self-contained.

The pass front matches the cardholder's QRLynx brand color. On iPhone, the layout follows Apple PassKit's "Generic Pass" template:

• Top-left: small logo (your QRLynx logo or your uploaded brand logo)
• Top-right: company name as logoText
• Header field: title (e.g. "Director of Engineering")
• Primary field (large center): full name
• Right of primary: cardholder's profile photo as a thumbnail (~90×90)
• Secondary row: company name, department
• Auxiliary row: phone, email
• Bottom strip: QR code linking back to qrlynx.com/@slug

Tapping the (i) icon flips the pass to the back, which lists every additional contact field — work phone, cell phone, website, full address, bio, plus a "View Online" link to refresh the live card.

On Android, Google Wallet renders the same data with their own card layout (logo top-left, name large, contact rows below, QR at the bottom). The visual is slightly different but the information density matches.

Both platforms automatically de-duplicate by issuer + serial number, so re-saving the same card from a different scan replaces the old pass in place rather than creating duplicates. If you update your card content (e.g., new job title), the recipient's pass doesn't auto-update — Apple supports push updates via APNs but it's rarely worth the operational complexity for a business card. Recipients who want fresh contact info just re-scan.

Wallet passes are static metadata at rest — neither Apple nor Google has access to the pass contents on the issuer's behalf. The pass content is encrypted with the user's device key when saved (iOS uses Secure Enclave; Android uses Keystore-backed credential storage). Apple does not phone home with pass content; Google retains pass class metadata server-side to support cross-device sync but the user's saved pass instances are tied to their Google account, not exposed in any developer-readable interface.

For card issuers like QRLynx, the privacy model is straightforward: we sign the pass once with our service account credentials, hand it to the user, and they save it. We don't see their saved-pass list, we don't get notifications when someone adds the pass, and the saved pass continues to work even if the user blocks our domain.

The QR code embedded on the back of the pass is a simple URL pointing back to qrlynx.com/@slug. When scanned, that hits our analytics — but only if the user actively re-shares the pass via the QR. Saving the pass alone produces zero signal on our end.

Bottom line: passing a wallet pass to someone is the most privacy-respecting digital-business-card share flow available in 2026. No app install means no advertising-ID handoff. No "view tracking" beacon fires when they open it. Their address book stays private to them. The compromise — versus a vCard QR — is that you (the issuer) lose a little visibility into who saved it, in exchange for friction-free recipient experience.

The most frequent failures we've seen on QRLynx and other digital-business-card platforms in 2026:

Apple Wallet: "Pass cannot be installed." Almost always a certificate expiration issue. Apple Pass Type ID certs are valid for 1 year and must be renewed via the Apple Developer Portal — set a calendar reminder. The other recurring cause is an unreachable image URL inside the pass JSON; Apple validates that icon.png is real PNG bytes inside the ZIP, not a URL reference (we burned 4 hours on this in production — the lesson is to bundle icons inside the .pkpass instead of referencing CDN URLs).

Google Wallet: "Something went wrong. Please try again." Two main culprits. First: image URLs referenced from the pass class or pass object that return 404. Google validates by fetching the URL server-side, so the image must be public, HTTPS, and small enough to fetch within their timeout. Second: account is in demo mode and the saver isn't an admin or test account on your issuer.

Both wallets: pass shows "[TEST ONLY]" or "Demo Pass." Google Wallet stamps this on every pass from an issuer that hasn't completed publishing-access review. Submit the request in the Pay & Wallet Console, wait 1-3 business days, the badge disappears automatically once approved. Apple Wallet has no equivalent — passes are fully live as soon as the cert is valid.

iPhone Chrome: tap does nothing. Chrome on iOS doesn't auto-trigger PassKit on the .pkpass MIME type the way Safari does. The user has to tap "Open in Safari" or use a long-press save-to-files flow. The fix is to send a Universal Link or "Open in Safari" prompt for iPhone Chrome users — most apps just rely on the user defaulting to Safari for wallet flows.

For the QRLynx implementation, all of the above are handled: certs are renewed via calendar reminder, icons are bundled inside the .pkpass (not URL-referenced), our Google issuer is approved out of demo, and the iPhone Chrome failure mode is documented in the FAQ on every card page.

• Apple Developer — PassKit Package Format Reference
• Google Developers — Generic Pass overview
• Apple — Add to Apple Wallet Guidelines (button branding)
• Google — Google Wallet brand guidelines
• RFC 6350 — vCard 3.0 specification (the format wallet passes ultimately interoperate with)
• Statista — Business cards: usage and disposal statistics

Related guides on QRLynx

• Digital Business Card — feature guide
• vCard QR Code — static contact card alternative
• Complete QR business card guide
• QRLynx vs HiHello — wallet feature comparison
• QRLynx vs V1CE — wallet feature comparison
• QRLynx vs Popl — Digital Business Card alternative