The age verification industry just crossed an inflection point. In April 2026, Apple expanded its Verify with Wallet API beyond airport TSA checkpoints to support age verification for apps and websites. Google’s Digital Credentials API — built on the same ISO 18013-5 standard — is already live for Android apps and Chrome-based web flows. Together, they cover roughly 99% of the smartphone market.
For platform operators who have spent years wrestling with document upload drop-off rates, selfie fatigue, and privacy complaints, this is the most significant infrastructure shift since biometric liveness detection went mainstream. But it’s not a silver bullet — and the platforms that treat it like one will find themselves with coverage gaps, compliance holes, and a false sense of security.
Here’s what you need to know.
What Changed: From Document Scans to Credential Presentations
Traditional age verification requires users to do something uncomfortable: hand over a government ID image or take a selfie for biometric analysis. Even the best implementations see 15-30% abandonment rates at this step. Users don’t trust the process, don’t have their ID handy, or simply bounce because the friction exceeds their motivation.
Wallet-based verification flips the model. Instead of uploading a document for server-side analysis, the user’s device presents a cryptographically signed credential directly from their digital wallet. The platform receives only the specific claim it requested — “this person is over 18” — verified against a government-issued credential, without ever seeing the underlying document, photo, or date of birth.
The technical difference is fundamental. Document upload verification works like a photocopy: you hand over a full image, and the verifier extracts what it needs. Wallet-based verification works like a notarized attestation: the device proves a specific fact, signed by an issuing authority, and reveals nothing else.
How Apple’s Verify with Wallet Works
Apple’s implementation is built on two complementary systems:
For native iOS apps, the Verify with Wallet API is available through the PassKit framework. Developers request an entitlement from Apple (granted per bundle ID), then invoke the API specifying which information they need. For age verification, the request is minimal — the API returns a boolean confirmation that the user meets the specified age threshold.
The user experience is a single tap. When the app triggers the verification request, iOS presents a system sheet showing exactly what information will be shared. The user authenticates with Face ID or Touch ID, and the credential is presented. No document scanning. No selfie. No third-party redirect.
For websites, Apple implemented Verify with Wallet on the Web using the W3C Digital Credentials API combined with the ISO 18013 mdoc format. Web developers can request age verification through standard browser APIs, and Safari handles the credential presentation natively. This was announced at WWDC25 and is now production-ready.
The privacy model is what makes this architecturally significant. Apple’s system uses selective disclosure — the credential proves a specific claim without revealing the full identity document. A platform verifying that a user is over 21 never sees their name, address, photo, or date of birth. The cryptographic proof is sufficient.
Apple has also added a verifyAge button label in the PassKit framework, giving developers a standardized UI element that users will learn to recognize and trust across apps.
How Google’s Digital Credentials API Works
Google’s approach is technically similar but strategically different. Rather than building a proprietary API, Google leaned heavily into the W3C Digital Credentials API standard, making their implementation inherently cross-platform.
For Android apps, the Digital Credentials API allows relying parties to request verifiable proof of identity or age from Google Wallet. The API supports mobile Driver’s Licenses (mDLs) and ID Passes, all adhering to the ISO 18013-5 standard.
For web-based verification, Chrome implements the Digital Credentials API as a browser-native feature. Websites call a standard JavaScript API, Chrome prompts the user to select a credential from their wallet, and the verification happens without any redirect or third-party widget.
Google’s onboarding process for relying parties takes 3-5 business days, and the documentation explicitly supports age verification as a primary use case — verifying age before purchasing age-restricted items or accessing age-restricted content.
A critical design choice: Google built the system to accept credentials from any compliant wallet, not just Google Wallet. If a user has an ISO 18013-5 compliant mDL in a state-issued wallet app, it works through the same API. This interoperability is a feature, not an accident — it’s how the system scales beyond Google’s ecosystem.
The Interoperability Question: ISO 18013-5 and W3C Digital Credentials
Both Apple and Google are converging on the same underlying standards:
ISO 18013-5 (also called “mdoc”) defines the data format and security model for mobile identity documents. Originally designed for mobile driver’s licenses, it supports selective disclosure natively — a credential holder can prove they’re over 18 without revealing their full license data.
W3C Digital Credentials API defines how web browsers request and receive digital credentials. It’s the browser-level plumbing that makes wallet-based verification work on the web without proprietary SDKs.
This convergence matters enormously. It means a single integration can theoretically accept credentials from Apple Wallet, Google Wallet, EU Digital Identity Wallets (under eIDAS 2.0), and state-issued mDL apps — all through the same API surface.
In practice, “theoretically” is doing heavy lifting in that sentence. The standards are aligned, but the implementations diverge in credential provisioning, trust chain validation, and error handling. A platform that implements only the Apple flow misses Android users. One that implements only the Google flow misses iOS users. And neither implementation covers users who haven’t provisioned a digital ID in their wallet — which, as of mid-2026, is still the majority.
What Wallet-Based Verification Doesn’t Solve
Here’s where the narrative gets complicated. Wallet-based age verification is genuinely better on every dimension that matters — privacy, user experience, accuracy, and speed. But it has structural limitations that platform operators must understand:
Coverage Gaps Are Real
Not every user has a digital ID in their wallet. Apple’s Digital ID requires a U.S. passport (or a state-issued ID in participating states). Google Wallet supports mDLs in select U.S. states, with international expansion ongoing. The EU Digital Identity Wallet won’t be universally available until late 2026 at the earliest.
For platforms with global audiences, wallet-based verification might cover 10-30% of users today. The rest still need alternative verification methods — document upload, biometric age estimation, open banking checks, or database lookups.
Jurisdictional Complexity Remains
Age verification regulations vary by jurisdiction, content type, and user age. A platform operating in the US, UK, EU, and Australia needs to support different legal frameworks, different age thresholds, and different acceptable verification methods. Apple and Google’s APIs provide the credential presentation layer, but they don’t solve the orchestration problem — routing users to the right verification method based on their jurisdiction, device, and available credentials.
Returning User Recognition
Wallet-based verification is stateless by design. Each verification request generates a new cryptographic proof. This is excellent for privacy but creates a UX problem: users must re-verify every session unless the platform implements its own token-based returning user system.
This is a solved problem — Xident’s token-based credential system already handles this — but it’s not something Apple or Google’s APIs address. They verify identity. They don’t remember it.
Not All Age Checks Are Binary
Some regulatory frameworks require more than a simple over/under check. Germany’s KJM standards, for example, require specific verification methodologies. France’s ARCOM standard requires double anonymity. The UK’s Online Safety Act requires “highly effective” age assurance. Wallet-based verification satisfies many of these requirements, but the compliance mapping is non-trivial and varies by regulator.
The Orchestration Layer: Why You Still Need a Verification Partner
This is the critical architectural insight: Apple and Google are building the credential presentation layer, not the verification orchestration layer. Their APIs are analogous to payment processors’ card-present APIs — essential infrastructure, but not a complete checkout solution.
A complete age verification implementation in 2026 needs to:
- Detect available credentials — Does this user have a wallet-based ID? An mDL? Nothing?
- Route to the optimal method — Wallet verification if available, biometric estimation or document check as fallback, open banking where supported.
- Handle jurisdictional rules — Different age thresholds, different acceptable methods, different regulatory frameworks.
- Manage returning users — Token-based recognition so verified users don’t repeat the process.
- Produce audit trails — Compliance evidence that satisfies regulators without storing PII.
- Gracefully degrade — If the wallet flow fails (expired credential, unsupported device, user cancels), the fallback must be seamless.
This is exactly what a verification orchestrator like Xident does. We’re integrating Apple’s Verify with Wallet and Google’s Digital Credentials API as first-class verification methods alongside our existing biometric age estimation, document verification, NFC chip reading, and open banking checks. When a user has a wallet-based credential, they get the one-tap experience. When they don’t, the system automatically falls back to the next-best method for their jurisdiction and device.
What This Means for the EU Digital Identity Wallet
The timing of Apple and Google’s wallet expansions isn’t coincidental. By December 2026, every EU member state must offer at least one EUDI Wallet to citizens under the eIDAS 2.0 regulation. The EU’s Age Verification Blueprint — which reached feature-ready status in April 2026 — is designed to work within this wallet ecosystem.
The convergence is deliberate. The EU’s technical specifications reference ISO 18013-5 and W3C Verifiable Credentials. Apple and Google’s implementations support these same standards. The result is a global identity infrastructure where a credential issued by France can be verified by a platform in the United States through a standardized API.
For platform operators, this means the investment in wallet-based verification today will pay dividends as the EU wallet ecosystem matures. The APIs are the same. The standards are the same. The coverage just keeps expanding.
Implementation Timeline: What to Do Now
If you’re a platform operator subject to age verification requirements, here’s the practical roadmap:
Immediate (Q2 2026):
- Integrate with a verification orchestrator that supports wallet-based credentials alongside traditional methods. Don’t build the routing logic yourself.
- Test Apple’s Verify with Wallet API in your iOS app using a development entitlement. The integration is straightforward — it’s a PassKit API call — but the entitlement approval process takes time.
- Implement the W3C Digital Credentials API for your web flows. Chrome and Safari both support it.
Near-term (Q3-Q4 2026):
- Monitor EU member state wallet rollouts and test credential acceptance as each becomes available.
- Benchmark wallet-based verification conversion rates against your existing flows. Expect significantly higher completion rates for users with provisioned credentials.
- Update your privacy policy and data processing documentation to reflect the reduced data collection of wallet-based flows.
Ongoing:
- Track ISO 18013-5 specification updates and new credential types.
- Monitor which US states add mDL support to Apple and Google’s platforms.
- Evaluate whether wallet-based verification satisfies specific regulatory requirements in your operating jurisdictions (UK Ofcom, France ARCOM, Germany KJM, Australia eSafety).
The Bottom Line
Wallet-based age verification is the best user experience the identity industry has ever produced. One tap, no documents, no selfies, cryptographic proof, minimal data exposure. Apple and Google have built the rails.
But rails aren’t routes. Platform operators still need an orchestration layer that routes users to the right verification method, handles the 70-90% who don’t yet have wallet credentials, manages jurisdictional complexity, and produces compliant audit trails.
The platforms that win are the ones that implement wallet-based verification as the preferred path while maintaining robust fallbacks — not the ones that wait for universal wallet adoption before acting, and not the ones that treat Apple or Google’s API as their entire compliance strategy.
Xident supports wallet-based credentials as part of our multi-method verification orchestration. If you’re evaluating how to integrate Apple Verify with Wallet or Google Digital Credentials alongside your existing age checks, talk to our team — we can have you live in days, not months.
