EUDI Wallet vs Apple Wallet vs Google Wallet: What Are You Actually Integrating?

Our first coverage model at Alentra gave each country one wallet slot. It was tidy. It was also wrong.

The mistake became obvious when we tried to place EUDI Wallet, Apple Wallet and Google Wallet on the same map. A country can have several credential issuers, several wallet apps and more than one technical route for presenting the same kind of identity data. The company whose logo appears on the phone may not issue the credential, define its legal effect or operate the browser API that carries it.

That is why EUDI Wallet vs Apple Wallet vs Google Wallet is a misleading comparison if it stops at features. The three names do not describe the same layer.

The short answer

EUDI Wallet is a regulated European identity ecosystem. Member States provide or recognize certified wallet solutions under common legal, technical and trust rules.

Apple Wallet is an Apple-controlled wallet application and presentation channel. It can carry supported government IDs and Apple's passport-derived Digital ID, then present information through Verify with Wallet in an app, on the web or in person where supported.

Google Wallet is Google's wallet application. Google's online verification route also uses the web's Digital Credentials API and Android Credential Manager, which are designed to let more than one compatible wallet answer a request.

Here is the comparison that is useful when planning an integration:

Question	EUDI Wallet	Apple Wallet	Google Wallet
What does the name describe?	A legal, trust and technical ecosystem with multiple national wallets	A wallet product and Apple verification interfaces	A wallet product plus Google-supported verification and onboarding routes
Who issues identity data?	Member-State PID providers and attestation issuers	A government authority for supported IDs; Apple for its passport-derived Digital ID	Government or other supported credential issuers
Typical online presentation	OpenID4VP and supported credential formats under the EUDI architecture	Verify with Wallet in app or on the web	Digital Credentials API on the web or Credential Manager on Android, using formats such as mdoc through OpenID4VP
Who approves the relying party?	National registration under the EUDI framework	Apple controls access, entitlements and reader configuration	Google supports direct RP onboarding and a verifier-registrar path for aggregators
What determines coverage?	Country, certified wallet, credential, issuer trust and registration	Supported document, issuing region, device, OS and approved request	Supported issuer, credential, device, browser and trusted request signer

The rows are deliberately uneven. Forcing them into a single “wallet provider” field throws away the information an identity service later needs to verify a result.

EUDI is the framework; the wallet apps come from its members

There will not be one EU-owned app installed by every European.

The EUDI Regulation requires each Member State to provide at least one European Digital Identity Wallet. A state can provide the wallet itself, mandate another provider or recognize an independently provided solution. The common part is the framework: certification, trust, relying-party registration, Person Identification Data, attestations and interoperable presentation rules.

The Commission's EUDI Toolbox makes the split unusually clear. It contains an Architecture and Reference Framework, a reference implementation and technical specifications. Those materials tell national wallets, issuers and service providers how to work together. They do not turn twenty-seven national identity systems into one vendor account.

For a business, “we support EUDI” therefore needs a second sentence. Which country? Which credential? Which wallet has been certified? Which issuer is trusted? Has the relying party been registered for the requested data?

Our complete EUDI Wallet guide covers the legal and rollout picture, while the maintained EUDI Wallet route page records Alentra's current implementation status. The narrower point here is architectural: EUDI belongs in a coverage model as a wallet family and trust framework, with national routes below it.

Apple Wallet is a carrier with its own front door

Apple's identity route starts with a supported identity document in Apple Wallet. The issuing authority verifies a government ID before it is added. The holder then authenticates on the device before approving a presentation.

Apple's Verify with Wallet overview says apps are entitled to request only the specific identity fields needed for the transaction. Apple's current availability list includes participating US jurisdictions, Puerto Rico, Japan's My Number Card and passport-derived Digital ID on supported devices. That list changes over time, so it is a poor candidate for a hard-coded country boolean.

In 2026 Apple also describes Verify with Wallet on the web. This matters for Alentra because the signer or identity holder should not need another Alentra mobile app. A hosted browser session can hand the transaction to a wallet already on the phone.

The browser handoff does not remove Apple's operating rules. The requesting business still needs the correct approval, domain and reader setup for its use case. The response must be decrypted and checked on a server. Supported identity fields depend on the document presented, not on a generic promise that “Apple Wallet supports identity.”

Read the maintained Apple Wallet route page for Alentra's current coverage and onboarding status.

Google Wallet is not the whole Digital Credentials API

Google's naming creates a different trap.

A person may hold an ID in Google Wallet. The website, however, can invoke the Digital Credentials API, a browser-mediated interface intended to offer compatible credentials from available wallets. Google itself recommends a generic entry point such as “Verify with digital ID” because options beyond Google Wallet may answer over time.

Google's digital identity overview describes online presentations using open standards including the W3C Digital Credentials API, OpenID4VP and ISO mdoc formats. On Android, Credential Manager performs the matching. The wallet then shows the relying party's name, logo, privacy policy and requested data before the user approves.

This distinction changes how a product should report a result. The transport may be a browser API supported by Google, while the selected wallet and credential issuer are separate facts. Recording all three as provider: google loses provenance.

Google has also published an aggregation route. Under its verifier-registrar onboarding model, an identity provider can operate a certificate authority, sign requests for downstream relying parties and notify Google as each customer is onboarded. The customer does not integrate directly with Google, but its name, use case and display metadata still exist in the approval chain.

That is closer to the operating model Alentra wants: a business deals with Alentra, while Alentra carries the provider work where the rules permit it. It is automation with a gate, not instant anonymous access.

The Google Wallet route page tracks the current implementation separately from the broader browser capability.

The credential issuer is the fact most diagrams omit

Wallet comparisons often draw three boxes: business, wallet, user. The issuer vanishes. Verification fails without it.

A mobile driver's licence presented from Apple Wallet still derives its authority from an issuing jurisdiction. A PID in a national EUDI wallet comes from an authorized PID provider. A credential returned through the Digital Credentials API needs a signature chain and trust basis the verifier recognizes.

The wallet protects keys, asks for consent and packages the presentation. The issuer makes the claims. The relying party decides whether those claims, that issuer and that transaction satisfy its policy.

This is also why a cryptographically valid response can be unusable. It may be signed by an issuer the relying party has not trusted. It may carry the wrong document type. It may disclose a birth date when the business registered only for an age threshold. Cryptography can prove the response was not altered; it cannot invent authorization.

What a business actually integrates

The phrase “wallet integration” hides at least seven moving parts:

1. Country or jurisdiction. This usually determines the identity authority and regulatory route.
2. Credential profile. PID, mDL, national ID, passport-derived Digital ID and age proof are different documents.
3. Issuer trust. The verifier needs current trust material and status information for the issuer.
4. Wallet or credential provider. This controls what the holder can store and present.
5. Presentation transport. Same-device, cross-device QR, browser-mediated and proximity flows behave differently.
6. Relying-party authority. The request must come from a registered or approved party with an allowed purpose and data scope.
7. Requested outcome. Identifying someone, checking an age threshold and binding a person to a document hash are separate jobs.

The visible button is the last step, not the data model.

Consider a future customer serving people in Sweden and the United States. A Swedish user may present national PID from a certified EUDI wallet. A US user may present an mDL from Apple Wallet or Google Wallet, depending on issuing state, device and enrollment. A browser might mediate more than one eligible wallet. The customer still wants one result shape, but the verifier cannot pretend those routes share one issuer, approval or trust chain.

The Alentra coverage explorer keeps country, wallet, credential and rollout state separate for this reason. The identity flow builder starts from the business outcome and then narrows the routes that can produce it.

The architecture change this forced in Alentra

We removed the assumption that a country owns one wallet. The replacement is a route ledger.

A route is closer to:

country + wallet family + credential profile + presentation adapter + trust state + onboarding state

That tuple is less attractive than a row of country flags. It is much more useful.

It lets Alentra answer questions a launch team will actually ask:

• Can this credential produce the requested primitive today?
• Does the business need to supply documents or complete provider approval?
• Can Alentra register the business as a downstream relying party?
• Which trust roots and verification policy apply to the returned credential?
• Is the route live, sandbox-only or still waiting on an external provider?

The adapter boundary also moved. An adapter should not be named after a wallet logo when several wallets can use the same presentation family. OpenID4VP, ISO mdoc, a provider-specific reader and a qualified-signature service have different request and validation behavior. The wallet remains recorded as evidence, but the code boundary follows the protocol and trust work.

That decision keeps EUDI from swallowing the rest of the product. EUDI is Alentra's first serious wallet family, not its final architecture.

Which route should a business choose?

Start with the fact the business needs.

If the service only needs to know whether someone is over eighteen, request an age result where the credential and wallet support it. If the service needs a legal name and date of birth, request those attributes and accept the added data-protection burden. If a person must approve exact terms or documents, identity presentation alone is incomplete; the flow also needs content binding and signature evidence.

Then look at the audience. Country, issuing authority, device mix and credential enrollment will narrow the available routes. A polished Apple flow is no fallback for a person whose government has not issued a supported document. A technically open browser API does not help when no eligible credential is present.

Finally, inspect onboarding. EUDI national registration, Apple approval and Google RP or verifier-registrar onboarding are product dependencies. Put them in the launch plan next to code and testing. Hiding them in an operations inbox turns “self-service” into a surprise queue.

Alentra's goal is to make that queue visible and handle it for customers whenever provider rules allow. The customer should choose countries, wallets and required outcomes in one place. The platform can then say what is automatic, what Alentra will submit and what still needs an action from the customer.

Frequently asked questions

Is EUDI Wallet available inside Apple Wallet or Google Wallet?

EUDI defines a European wallet framework and certified national wallet solutions. Apple Wallet and Google Wallet are separate wallet products. Future credential interoperability may create overlapping routes, but support must be checked for the exact credential, issuer, wallet and protocol. Do not assume an EUDI credential appears in either platform wallet because all three use digital-credential standards.

Does integrating the Digital Credentials API mean supporting only Google Wallet?

No. The browser API is designed to mediate requests to compatible credential providers. Google Wallet is one possible provider. The returned response still needs enough metadata and evidence to identify the selected wallet, credential and issuer.

Can one country support several identity wallets?

Yes. A country can have multiple national or recognized wallets, platform wallets and credential-specific applications. Coverage should be modeled as routes, not as one wallet field on a country record.

Can one API normalize all three?

It can normalize the business-facing request and result. It should not erase route-specific verification. Trust roots, request signing, relying-party authority, response formats and retained evidence still need the correct adapter and policy behind the API.

Should the button name a specific wallet?

Sometimes. A provider-specific route may require provider branding. A browser-mediated multi-wallet request is usually better served by a neutral label such as “Verify with digital ID,” followed by the system's wallet chooser. The interface should not promise a wallet that cannot answer the request.

A wallet logo is useful on a button. It is a poor database key.

Provider documentation and availability change. This article reflects public EUDI, Apple and Google materials checked on 22 August 2026 and does not promise production access to a particular credential or country.