Digital Credentials & Payments: Apple vs. Google Wallet Strategy

Digital payments are always changing. We want them to be faster, safer, and easier to use. At the same time, digital ID tools, like Verifiable Credentials (VCs) and mobile identity documents (mdocs), are improving. They offer new ways for people to show who they are. So, the big question is: can these new digital IDs also make digital payments much better or simpler?

This article looks at how digital credentials (including ISO mdocs and VCs sent using OpenID4VC) connect with the world of payments. We will cover:

• How current phone wallets (Apple Wallet, Google Wallet) handle ID information versus payment cards.
• Why current digital ID standards like ISO 18013-5/7 mdocs are not really suitable as direct payment tools.
• What role protocols like OpenID4VC could play in future payment methods.
• How other (third-party) wallet apps might handle payment features.
• The main problems and what could happen in the future when trying to use verifiable credentials in payment systems.

This text adds to our other discussion on Digital Credentials & Passkeys by focusing just on payments.

To see how digital credentials could be used in payments, we first need to understand how today's main mobile platforms and their built-in wallets (Apple Wallet, Google Wallet) keep identity information separate from how payments are processed.

Native platform wallets have become sophisticated hubs for users, but they typically maintain a clear distinction between identity credentials and payment instruments:

• Identity Credentials (e.g., mDLs):
  • Apple Wallet: Primarily supports ISO/IEC 18013-5 compliant mobile driver's licenses (mDLs) and state IDs. As of WWDC25, Apple has confirmed that Safari 26 (in iOS 26) will support the W3C Digital Credentials API for online presentation, with an exclusive focus on the org.iso.mdoc protocol. This is for verifying identity attributes (e.g., name, age, address), not for payments.
  • Google Wallet & Android Credential Manager: Google Wallet also supports mDLs based on ISO 18013-5. The underlying Android Credential Manager provides a more flexible framework. While its implementation of the Digital Credentials API is protocol-agnostic, Android provides a default implementation that uses OpenID4VP as the transport mechanism.
• Payment Instruments (e.g., Credit/Debit Cards):
  • Both Apple Pay (within Apple Wallet) and Google Pay (within Google Wallet) utilize established, highly regulated payment technologies. These are primarily based on EMV (Europay, Mastercard, Visa) standards, involving tokenization (Device PANs or DPANs replacing actual card numbers for transactions), secure elements or hardware-backed security for storing payment tokens, and dynamic cryptograms for transaction security.
  • These payment systems interact directly with existing payment networks (Visa, Mastercard, Amex, etc.) and acquiring banks.

Key Takeaway: Native platform wallets currently operate with separate "stacks" or technologies for identity credentials versus payment cards. An mdoc is presented for proving an identity attribute; a tokenized card is presented for making a payment. There is no direct use of an mdoc as a payment instrument within these native ecosystems.

The ISO/IEC 18013-5 standard defines the data structure for mDLs and other mobile IDs (mdocs). While excellent for identity verification, its design is unsuited for direct use as a payment instrument:

Even if an mdoc could theoretically have custom data fields added to hold a PAN or a payment token (as ISO 18013-5 allows for custom namespaces), the mdoc standard itself does not define:

• How to generate or process dynamic payment cryptograms.
• How to perform online authorization with a payment network.
• The necessary security mechanisms specific to payment transactions (beyond identity data integrity).

Thus there is currenty no way to use ISO 18013-5 mdoc as a direct payment instrument.

While an mdoc isn't a payment tool, it can play a role in a "step-up authentication" flow, where a user's identity must be explicitly verified for a high-risk action. This is distinct from using it to execute the payment itself. The flow would typically look like this:

1. Primary Authentication: The user logs into a service, often with a low-friction method like a passkey.
2. Trigger for Step-Up: For a high-assurance action (e.g., a large bank transfer, updating personal details), the service requires an explicit identity check.
3. mdoc Presentation: The service requests a presentation of the user's mdoc (e.g., driver's license). The user presents the required attributes from their wallet.
4. Verification: The service cryptographically verifies the mdoc data against a trusted source or a previously registered identity.

In this model, the mdoc provides strong, phishing-resistant proof of identity for a specific, high-risk moment. However, the financial transaction that follows still uses established payment rails. The mdoc verifies the person, not the payment method.

While mdocs themselves are not payment instruments, protocols like OpenID for Verifiable Credentials (OpenID4VC – encompassing OpenID4VP for presentation and OpenID4VCI for issuance) offer a more flexible transport layer.

Key Characteristics of OpenID4VC:

• Protocol, Not Payload: OID4VC defines how to request and present VCs but is largely agnostic about the format of the VC payload itself. It can transport mdocs, W3C standard VCs (e.g., in JWT or SD-JWT format), or other custom credential types.
• Use-Case Breadth: This flexibility allows platforms like Android (via its Credential Manager) to support requests for various types of credentials through a common mechanism.
• Future Compatibility for Payment VCs: If the payments industry were to standardize a verifiable "payment token" or "payment authorization" credential format, OID4VC could theoretically transport such a credential between a user's wallet and a merchant/PSP.

However, OID4VC Itself is Not a Payment Solution:

• OID4VC's role is to facilitate the exchange of a credential. It does not define the payment credential's content, security features, or how it interacts with payment processing systems.
• For OID4VC to be useful for payments, a widely adopted, secure, and standardized verifiable payment credential format would first need to be developed and supported by the payments ecosystem (issuers, acquirers, networks). This does not currently exist.

Beyond native platform wallets, a growing ecosystem of third-party wallets (e.g., EUDI Wallet, bank-provided wallets, specialized industry wallets) is emerging. These wallets must navigate the fundamental difference between fast, low-friction authentication and high-assurance attribute verification, especially in payment contexts.

The emerging consensus is that passkeys are ideal for the core authentication to a payment service, as they are phishing-resistant and designed for a seamless user experience. Injecting a digital credential presentation into the critical payment confirmation step would add significant friction and likely harm conversion rates. Therefore, digital credentials' primary role is in the one-time, high-assurance onboarding and KYC phase that enables payment capabilities, rather than in the transaction itself. How might these wallets approach payments, especially in conjunction with digital identity features?

For a third-party wallet to authorize a payment, it needs a way to be invoked by the merchant's app or website. There are several established interaction models for this, each with different levels of platform integration and user experience:

• App-to-App Deep Linking: This is a universal method where the merchant's application (native or web) redirects the user to the third-party wallet app using a custom URL scheme (e.g., eudi-wallet://...). The transaction details are passed as parameters in the URL. After the user confirms the payment in the wallet app, it redirects back to the merchant app using another deep link. This works on both iOS and Android but involves a visible context switch between apps.
• Native Wallet Selection: With Native Wallet Selection an application can invoke a generic system service that displays all registered payment handlers or wallets. The user can then select their preferred wallet from a system-provided UI. This offers a more integrated feel than simple deep linking (Digital Credential API).
• Simple QR Code-Based Payments: This model is ideal for desktop-to-mobile flows. The merchant's website displays a QR code containing the transaction details or a URL. The user scans this code with their mobile wallet app, which then independently handles the confirmation on the phone. The wallet's backend then communicates the approval back to the merchant's system.
• Standardized Cross-Device Flows (FIDO CTAP): An evolution of the QR code method, this uses protocols like FIDO's Client to Authenticator Protocol (CTAP) to create a direct, secure, and encrypted channel between the desktop browser (client) and the mobile wallet (acting as an authenticator). This is more secure than simple QR codes as the browser and phone communicate directly, a model heavily supported by Google for both passkeys and digital credentials.
• Direct Backend Integration: In some closed-loop systems, the third-party wallet app might interact directly with a Payment Service Provider (PSP) or a financial institution's backend to process payments, often using proprietary APIs.

These models provide the "transport layer" for initiating a payment confirmation, within which a cryptographic flow (like the one detailed for the EUDI Wallet) can then take place.

With the announcements at WWDC25, the landscape for how browsers handle digital credentials has become much clearer, solidifying the separation between identity verification and payment processing. Platforms are enabling third-party wallets to interact with browsers for identity verification via the W3C Digital Credentials API, but the approaches are diverging:

• Apple's Stance (Confirmed at WWDC25): Apple officially announced support for the Digital Credentials API in Safari 26 (shipping with iOS 26). As detailed in their "Verify identity documents on the web" session, the implementation exclusively supports the org.iso.mdoc protocol. This allows websites to request verifiable information from mdocs in Apple Wallet or other registered third-party document provider apps, but it does not support the more general-purpose OpenID4VP protocol.
• Google's Stance: Android's Credential Manager allows third-party wallets to register as handlers for credential requests. Its implementation of the Digital Credentials API in Chrome focuses on using OpenID4VP as the primary transport protocol. While OpenID4VP can carry an mdoc as a payload, the protocol itself is different from Apple's direct org.iso.mdoc approach.

Crucially, these browser integrations are for identity attributes, not for treating the presented mDoc or VC as a payment instrument.

If a user presents an mDL from their wallet to a website via the browser's Digital Credentials API, that website might use the information for address pre-fill or age verification during checkout. However, the actual payment step would still require a separate interaction with a payment method (e.g., Apple Pay, Google Pay, or entering card details). The browser API itself is not designed to initiate or process a financial transaction using an identity credential.

The EU Digital Identity (EUDI) Wallet serves as an excellent case study for how a third-party wallet must navigate the complex, real-world landscape of operating systems and API availability. Among its many functions, two of the most prominent use cases are identity verification and payment confirmation, and the technical pathways to accomplish these two tasks are different, especially when comparing Android's flexible framework to Apple's more rigid implementation.

The following table breaks down how the EUDI Wallet can be invoked for either identity verification or payment authorization, highlighting the differing support across platforms.

Key Takeaways from the Comparison:

• Digital Credentials API: This emerging W3C standard is protocol-agnostic and well-supported for identity on both platforms. For its implementation, Android provides a default flow using the flexible OpenID4VP protocol, which can carry various credential formats. Apple's implementation, in contrast, is strictly for the org.iso.mdoc format. Crucially, browsers scope this API for identity use cases, not for initiating payments.
• Native Wallet Selector: Both operating systems provide a native UI to select a wallet, but with different limitations. Android offers a selector for both identity and payment apps. iOS provides a selector for registered identity "Document Provider" apps but does not offer one for third-party payment apps.
• App-to-App Deep Linking: This is the universal workhorse, functioning reliably for both identity and payment use cases on both platforms. It remains the primary method for invoking a third-party wallet for payments on iOS.
• Standardized Cross-Device: This FIDO CTAP-based flow is currently a feature of the Google/Android ecosystem and is not supported on iOS.

(*) Note on Payments via DC API: While Android's use of OpenID4VP makes a payment flow technically feasible through the Digital Credentials API, this is not its primary design focus. Seamless integration for payments via this specific API, as opposed to other native methods, remains to be seen and would require explicit support from browser vendors.

This comparison makes it clear that while identity verification is increasingly being standardized through the Digital Credentials API, payment authorization for third-party wallets like the EUDI Wallet still relies heavily on more traditional native integration patterns like app-to-app deep linking, especially on iOS.

Regardless of which payment integration model is used to invoke the wallet, the core of the EUDI Wallet's payment confirmation relies on a standardized cryptographic flow detailed in EWC RFC008.

Below is a high-level walk-through of this process:

This is a non-normative example of the payment_data object that is sent to the wallet, detailing the transaction for the user to confirm.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

After the user approves, the wallet creates a key-binding JWT. Its claims prove that the user confirmed the specific transaction data.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

While the technical standards are evolving, the payment industry is not standing still. Key players are actively exploring how to merge the security of digital credentials with the functionality of payments.

A powerful way to understand the potential of Verifiable Credentials (VCs) is to compare them to the successful network payment tokenization systems (like Visa Token Service or Mastercard MDES).

• Payment Tokenization replaced the sensitive Primary Account Number (PAN) with a secure token and a one-time cryptogram. This protects the core asset—the card number—during transactions.
• Verifiable Credentials aim to do for personal data what tokenization did for PANs. Instead of sharing raw data (name, DOB, address), the user presents a cryptographically signed credential from a trusted issuer.

In essence, a VC is to personal data what a payment token and cryptogram are to card data: a secure, verifiable substitute that reduces risk and enhances privacy.

Building on this parallel, industry bodies are working on the concept of a "verifiable payment credential." This would be a credential, issued by a bank, that packages a payment instrument (like a tokenized card) and can be used to authorize transactions.

• EMVCo, the standards body for secure payments, is actively integrating FIDO standards into the EMV 3-D Secure protocol. This allows prior passkey authentications to be used as a strong signal for frictionless approvals, while also preparing for Secure Payment Confirmation (SPC) to serve as a modern, phishing-resistant alternative to traditional OTP challenges. There are also ongoing discussions on how verifiable credentials could be incorporated into these flows in the future.
• Visa has announced the Visa Payment Passkey Service, which securely binds a FIDO authenticator to payment credentials. This service is designed to confirm identity and authorize payments in a single, frictionless step without interrupting the checkout experience.
• Mastercard is following a parallel strategy with its Mastercard Payment Passkey Service, which leverages its Token Authentication Service (TAS) to replace passwords and OTPs with passkey-based biometric authentication, tightly integrated with its tokenization services (MDES).

This shows a clear trend: the industry is moving toward a future where a wallet can present a cryptographically verifiable proof of both identity and payment authorization in a single, standardized flow.

Much of this innovation is being accelerated by strong regulatory tailwinds, particularly from the European Union.

The EU's eIDAS 2.0 regulation is not just about providing citizens with a digital ID; it explicitly envisions the EUDI Wallet as a method for performing SCA for online payments. This means that in the future, banks and payment providers in the EU may be required to accept the EUDI Wallet as a way for users to confirm online transactions, providing a standards-based alternative to proprietary banking apps or SMS codes.

A landmark antitrust settlement in the EU has already forced Apple to open its previously closed NFC interface on iPhones. As of iOS 17.4 (released March 5, 2024), Apple has implemented the necessary APIs and allowed users to select a default contactless payment app, meeting the European Commission's binding deadline of July 25, 2024. This is no longer a future prospect; it is the current reality in the European Economic Area (EEA).

This shift means that third-party wallet apps can now offer their own tap-to-pay solutions on iOS, ending Apple Pay's long-standing monopoly. Key capabilities now available to developers include:

• Default Wallet Choice: Users in the EEA can set an eligible third-party app as their default contactless payment application, which can be invoked via a side-button double-click.
• Full Integration: These wallets can use the iPhone's native security features, including Face ID and Touch ID, for payment authorization.
• Real-World Adoption: Several major players have already launched their solutions, including Vipps MobilePay in Norway and PayPal in Germany.

The implications of this opening are significant and already unfolding:

• Increased Competition: Banks and fintechs can now compete directly with Apple Pay on its own platform, which is expected to drive down issuer fees and spur innovation.
• Broader Credential Use: The same APIs can be used for more than just payments, including corporate badges, transit passes, and hotel keys, without needing to be in Apple Wallet.
• A Pathway for Standardized Credentials: This sets a crucial precedent. The same regulatory logic that opened the NFC interface for payment apps could eventually be used to mandate support for standardized, neutral "Verifiable Payment Credentials" (like those being piloted for the EUDI Wallet), allowing them to function alongside proprietary solutions.
• Global Precedent: While the change is currently limited to the EEA, it sets a powerful global precedent. Regulators in other regions, including the U.S., are closely watching, and this could accelerate similar openings worldwide.

For payment issuers (banks, schemes, fintechs), navigating the shift to digital credentials requires a pragmatic, phased strategy. The goal is to build on assets you control today to prepare for the ecosystem of tomorrow. This playbook outlines that strategy, moving from immediate, low-regret actions to more strategic, long-term evaluations.

The foundation of any future wallet strategy is a secure, widely adopted native app. The immediate priority is to maximize your app's reach and fortify its authentication for both login and payments.

1. Drive Native App Adoption: Your mobile app is your future wallet. The primary objective is to make it an indispensable tool for your customers. This distribution and engagement is the critical foundation for any future credential issuance or wallet functionality.

2. Use Passkeys for Payments, Following the PayPal Model: Deploy passkeys immediately, not just for login, but for payment authorization. Aim for an experience with close parity to native platform solutions like Apple Pay. For regulatory environments requiring Strong Customer Authentication (SCA), adopt PayPal's pragmatic approach:

   • Leverage passkeys as a primary authentication factor.
   • Combine them with trusted device signals (e.g., "remembered devices" managed via your app or secure cookies) to meet the "possession" factor of SCA.
   • This combination allows you to provide a seamless, low-friction payment confirmation experience that is both highly secure and compliant, without waiting for universal VC support.

With a secure, passkey-protected app as your foundation, you can begin to selectively integrate new credential technologies where they offer clear value.

3. Monitor the Rise of Verifiable Payment Credentials: The concept of a VC that carries a payment token is powerful but not yet standardized. Your role here is to be an active observer and participant.

   • Action: Closely track the progress within standards bodies like EMVCo and the W3C. Be prepared to leverage standardized Verifiable Payment Credentials if and when they provide a clear advantage over existing passkey-based flows.

4. Integrate Digital Credentials for Identity Use Cases: As digital identity wallets (like the EUDI Wallet) gain traction, integrate the Digital Credentials API for identity-related tasks, not payments.

   • Action: Use VC presentations for high-assurance processes where they excel:
     • Onboarding & KYC: Streamline new account setup.
     • Step-Up Authentication: Verify identity for high-risk actions.
     • Account Recovery: Provide a secure path for users who have lost their devices.

The ultimate barrier to adoption for any new payment technology is user friction. Before displacing a simple passkey flow, a VC-based alternative must prove it is not only more secure but equally seamless.

5. Benchmark Relentlessly Against the One-Click Experience: The standard for a modern payment experience is set by leaders like Apple Pay and its close follower on the Web, PayPal. Any new flow you introduce must compete with their near-instant, one-click confirmation. All current signals indicate that for the vast majority of transactions, the phishing resistance of passkeys provides a sufficient level of protection and a superior user experience. Do not add a VC presentation step to a payment flow if it introduces any discernible friction.

6. Watch for In-Band Device Signals within WebAuthn: The evolution of passkeys is not static. While early attempts at providing device-specific signals were discontinued, standards bodies are actively working on integrating stronger device-binding trust signals directly into the WebAuthn protocol. This would allow an RP to identify a trusted device during a passkey authentication, further strengthening the signal for risk engines without requiring a separate, out-of-band VC presentation. Monitor this space closely, as it is the most likely path to enhanced security without sacrificing the passkey's frictionless experience.

By following this phased playbook, an issuer can build a robust, practical strategy that maximizes security and enhances user experience today, while preparing to thoughtfully adopt the verifiable payment technologies of tomorrow.

For digital credentials to become integral to payment processes beyond just supporting KYC or authenticating users to payment accounts, several significant challenges must be addressed:

1. Standardization of Payment-Specific VCs: A dedicated, secure, and widely accepted verifiable credential format for payments needs to be developed. This would need to encapsulate payment tokens, transaction-specific data, and potentially dynamic security elements, far exceeding the scope of current identity-focused mdocs or generic VCs.
2. Integration with Payment Networks: Any VC-based payment solution must seamlessly integrate with existing global payment networks (Visa, Mastercard, etc.) or propose viable new rails. This involves complex technical, security, and business model alignments.
3. Regulatory Compliance: Payments are heavily regulated (e.g., PSD2/SCA in Europe, PCI DSS globally). A VC-based payment system would need to meet all relevant financial regulations, including those for security, consumer protection, and anti-fraud.
4. Issuer and Acquirer Adoption: Banks, financial institutions (as issuers of payment VCs), and merchant acquirers would need to invest in the infrastructure to support such a system.
5. Security Model: A robust security model specifically for payment VCs would be essential, covering issuance, storage (ideally in hardware-backed secure elements), presentation, and revocation in a financial context.
6. User Experience: While VCs can offer user control, the payment experience must remain fast, intuitive, and reliable to gain widespread adoption.

Future Possibilities:

• VCs for Payment Authorization Slips: VCs could represent a cryptographically signed "authorization" to pay from a linked account, presented via OpenID4VP, with the actual funds transfer still occurring through traditional rails.
• VCs Containing Payment Tokens: A standardized VC could be defined to securely hold a payment token (similar to an EMV DPAN), which is then processed by existing payment infrastructures.
• Closed-Loop Payment VCs: Specific issuers or communities might create VCs for payments within their own closed-loop systems.

However, these are largely conceptual at present. The primary drive behind current VC and mdoc development, now solidified by the concrete implementations of browser APIs, remains focused on identity verification and attribute attestation, not payment execution.

The convergence of digital identity and payments presents a complex but navigable landscape. While the promise of a single, universal "verifiable payment credential" is compelling, this article concludes that the most effective and practical strategy for payment issuers today is grounded in a different reality: the battle for the best user experience is paramount, and passkeys are the most powerful weapon.

The strategic playbook is clear. The immediate, low-regret move is to focus on establishing an unbeatable native app, using it as a vehicle to deploy passkey-based payments that can rival the frictionless "one-click" standard set by Apple Pay and PayPal. This approach addresses the core needs of security (through phishing resistance) and user experience today, using mature, widely adopted technology.

In this model, Verifiable Credentials find their crucial, but distinct, role. They are not yet the tool for the payment act itself, but are indispensable for the high-assurance identity tasks that surround it: secure onboarding, robust account recovery, and regulatory KYC.

The future of payments will not be determined by a single technology but by a relentless focus on the user. Success will come to issuers who master the passkey-driven experience in their own apps first, while thoughtfully monitoring the evolution of verifiable credentials and in-band passkey trust signals. They must be ready to integrate these new technologies not when they are merely available, but only when they can meet the formidable benchmark of a truly seamless, secure, and superior payment experience.