--- url: 'https://www.corbado.com/blog/digital-credentials-payments' title: 'Digital Credentials & Payments: Apple vs. Google Wallet Strategy' description: 'Learn how digital credentials impact payments and issuer strategies to compete effectively with Apple Pay and Google Wallet.' lang: 'en' author: 'Vincent Delitz' date: '2025-06-17T20:08:22.797Z' lastModified: '2026-03-27T07:01:34.966Z' keywords: 'digital credentials payment' category: 'Passkeys Strategy' --- # Digital Credentials & Payments: Apple vs. Google Wallet Strategy ### Summary: An Issuer's Strategic Playbook | Phase | Your Core Strategy | Key Actions | | :--------------- | :---------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Now** | πŸ“± **Push the App, Master Passkeys** | Drive native app adoption relentlessly. Use passkeys for a one-click payment experience that rivals Apple Pay & PayPal. | | **2. Near-Term** | πŸ†” **Use VCs for Identity, Not Payments** | Integrate digital credentials for high-assurance tasks like KYC and account recovery. Monitor, but don't rush into, verifiable payment credentials. | | **3. Future** | βš–οΈ **Evaluate VCs vs. Evolving Passkeys** | Benchmark any VC payment flow against the best. Adopt for payments only when mandated or if they provide superior net value. Watch for passkey enhancements like in-band device signals. | ## Key Facts - Apple and Google diverge on digital credential protocols: Apple's Safari 26 supports only `org.iso.mdoc` while Android uses **OpenID4VP**, but neither platform treats identity credentials as payment instruments. - **ISO 18013-5 mdocs** cannot function as direct payment instruments: the standard lacks dynamic cryptogram generation, online authorization mechanisms and payment-network integration. - Apple opened its **NFC interface** in the EEA as of iOS 17.4 (March 2024), ending Apple Pay's monopoly and enabling third-party tap-to-pay wallets on iPhones. - Issuers should deploy passkeys for payment authorization now using the **PayPal SCA model**: passkeys combined with trusted device signals, without waiting for verifiable payment credential standardization. ## 1. Introduction Digital [payments](https://www.corbado.com/passkeys-for-payment) are always changing. We want them to be faster, safer, and easier to use. At the same time, [digital ID](https://www.corbado.com/blog/digital-identity-guide) tools, like [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (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](https://www.corbado.com/passkeys-for-payment) much better or simpler? This article looks at how [digital credentials](https://www.corbado.com/blog/digital-credentials-api) (including ISO [mdocs](https://www.corbado.com/glossary/mdoc) and VCs sent using [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)) connect with the world of [payments](https://www.corbado.com/passkeys-for-payment). We will cover: - How current phone [wallets](https://www.corbado.com/blog/digital-wallet-assurance) (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) handle ID information versus [payment](https://www.corbado.com/passkeys-for-payment) cards. - Why current [digital ID](https://www.corbado.com/blog/digital-identity-guide) standards like [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 [mdocs](https://www.corbado.com/glossary/mdoc) are not really suitable as direct [payment](https://www.corbado.com/passkeys-for-payment) tools. - What role protocols like [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) could play in future [payment](https://www.corbado.com/passkeys-for-payment) methods. - How other (third-party) [wallet](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/blog/digital-credentials-api) & Passkeys by focusing just on payments. ## 2. Understanding the Current Landscape: Identity vs. Payment Stacks To see how [digital credentials](https://www.corbado.com/blog/digital-credentials-api) could be used in payments, we first need to understand how today's main mobile platforms and their built-in [wallets](https://www.corbado.com/blog/digital-wallet-assurance) (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) keep identity information separate from how payments are processed. ### 2.1 Native Platform Wallets: Separate Silos for Identity and Payments Native platform [wallets](https://www.corbado.com/blog/digital-wallet-assurance) 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](https://www.corbado.com/blog/wwdc25-passkeys-os26), Apple has confirmed that Safari 26 (in [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)) will support the W3C [Digital Credentials API](https://www.corbado.com/blog/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](https://www.corbado.com/blog/how-to-use-google-pay) also supports [mDLs](https://www.corbado.com/blog/mobile-drivers-license) based on [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5). The underlying [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Manager provides a more flexible framework. While its implementation of the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) is protocol-agnostic, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) provides a default implementation that uses [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) as the transport mechanism. - **Payment Instruments (e.g., Credit/Debit Cards):** - Both [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) (within Apple Wallet) and [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) (within Google Wallet) utilize established, highly regulated payment technologies. These are primarily based on EMV (Europay, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Visa](https://www.corbado.com/blog/visa-passkeys)) standards, involving tokenization (Device [PANs](https://www.corbado.com/glossary/pan) 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](https://www.corbado.com/blog/mastercard-passkeys), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/mdoc) _as_ a payment instrument within these native ecosystems. ### 2.2 Why ISO 18013-5 mdocs Are Not Payment Instruments The ISO/IEC 18013-5 standard defines the data structure for [mDLs](https://www.corbado.com/blog/mobile-drivers-license) and other mobile IDs (mdocs). While excellent for [identity verification](https://www.corbado.com/blog/digital-identity-guide), its design is unsuited for direct use as a payment instrument: | Feature | ISO 18013-5 Specifies (for Identity mdocs) | Why This is a Problem for Payments | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Primary Scope** | Mobile Driver's Licences & other identity documents. | Card networks need payment-specific data elements & cryptograms. | | **Data Model** | Fixed identity-related data elements (e.g., portrait, name, date-of-birth). Extensible, but still keyed to an "identity" namespace. | Card PANs, tokenized DPANs, CVMs, dynamic cryptograms don't map cleanly to these identity elements. | | **Threat Model & Security** | Holder-present ("attended") verification; offline "tap-to-verify" with selective disclosure for identity attributes. Secure data retrieval from the mdoc. | Payments require robust mechanisms for online authorization, dynamic cryptogram generation (EMV-style), fraud prevention specific to financial transactions, and links to funding sources. mdoc security is for identity integrity, not financial transaction processing. | | **Standard Acknowledgement** | ISO 18013-5 explicitly limits itself to in-person ID. ISO/IEC 18013-7 and ISO/IEC 23220 specify online presentation mechanisms for mdocs (e.g., for web-based identity verification via the Digital Credentials API), but these still focus on _remote identity verification_, not payment rails. | Payments, especially online, remain out-of-scope for the mdoc standards themselves. | Even if an [mdoc](https://www.corbado.com/glossary/mdoc) _could_ theoretically have custom data fields added to hold a [PAN](https://www.corbado.com/glossary/pan) or a payment token (as [ISO 18013-5](https://www.corbado.com/glossary/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. ### 2.3 Step-Up Authentication: Using mdocs for Identity Proofing, Not Payment While an mdoc isn't a payment tool, it can play a role in a "[step-up authentication](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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_. ## 3. The Role of OpenID4VC in Potential Payment Scenarios While [mdocs](https://www.corbado.com/glossary/mdoc) themselves are not payment instruments, protocols like OpenID for Verifiable Credentials (OpenID4VC – encompassing [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) for presentation and [OpenID4VCI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/merchant)/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk). **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](https://www.corbado.com/glossary/acquirer), networks). This does not currently exist. ## 4. Third-Party Wallets and Payments 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](https://www.corbado.com/blog/digital-credentials-passkeys#34-payment-scenarios-low-friction), as they are [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/logins-impact-checkout-conversion). Therefore, digital credentials' primary role is in the one-time, high-assurance onboarding and [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) phase that enables payment capabilities, rather than in the transaction itself. How might these wallets approach payments, especially in conjunction with [digital identity](https://www.corbado.com/blog/digital-identity-guide) features? ### 4.1 Current Interaction Models for Payments For a third-party wallet to authorize a payment, it needs a way to be invoked by the [merchant's](https://www.corbado.com/glossary/merchant) 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](https://www.corbado.com/glossary/merchant) 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](https://www.corbado.com/glossary/merchant) app using another deep link. This works on both [iOS](https://www.corbado.com/blog/webauthn-errors) 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](https://www.corbado.com/glossary/merchant) website displays a [QR code](https://www.corbado.com/blog/qr-code-login-authentication) 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](https://www.corbado.com/blog/digital-wallet-assurance) backend then communicates the approval back to the merchant's system. - **Standardized Cross-Device Flows (FIDO CTAP):** An evolution of the [QR code](https://www.corbado.com/blog/qr-code-login-authentication) method, this uses protocols like FIDO's Client to [Authenticator](https://www.corbado.com/glossary/authenticator) Protocol (CTAP) to create a direct, secure, and encrypted channel between the desktop browser (client) and the mobile wallet (acting as an [authenticator](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (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. ### 4.2 Browser Integration: Identity First, Payments Separate With the announcements at [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), 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](https://www.corbado.com/blog/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](https://www.corbado.com/blog/ios-26-passkeys)). As detailed in their ["Verify identity documents on the web" session](https://developer.apple.com/videos/play/wwdc2025/232/), 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](https://www.corbado.com/glossary/open-id-4-vp) protocol. With increasing support for digital credentials and enhanced web integrations, maintaining system performance and security becomes even more crucial - tools like [CleanMyMac](https://cleanmymac.com/) help ensure your Mac runs smoothly as these technologies evolve. - **Google's Stance:** [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) 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](https://www.corbado.com/blog/mobile-drivers-license) 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](https://www.corbado.com/blog/how-to-use-apple-pay), [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay), or entering card details). The browser API itself is not designed to initiate or process a financial transaction using an identity credential. ## 5. The EU Digital Identity Wallet in Practice The EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide) (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](https://www.corbado.com/blog/digital-identity-guide) and payment confirmation, and the technical pathways to accomplish these two tasks are different, especially when comparing [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) flexible framework to Apple's more rigid implementation. ### 5.1 Interaction Model Comparison: Identity vs. Payment 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. | Integration Model | Identity (Android) | Identity (iOS) | Payment (Android) | Payment (iOS) | | :---------------------------- | :----------------: | :------------: | :---------------: | :-----------: | | **Digital Credentials API** | βœ… | βœ… | βœ…\* | ❌ | | **Native Wallet Selector** | βœ… | βœ… | βœ… | ❌ | | **App-to-App Deep Linking** | βœ… | βœ… | βœ… | βœ… | | **Standardized Cross-Device** | βœ… | ❌ | βœ… | ❌ | **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](https://www.corbado.com/blog/webauthn-errors) 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](https://www.corbado.com/blog/webauthn-errors). - **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](https://www.corbado.com/blog/how-to-enable-passkeys-android) 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](https://www.corbado.com/blog/digital-identity-guide) 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. ### 5.2 Under the Hood: The EWC Payment Confirmation Flow Regardless of which payment integration model is used to invoke the wallet, the core of the EUDI [Wallet's](https://www.corbado.com/blog/digital-wallet-assurance) payment confirmation relies on a standardized cryptographic flow detailed in [`EWC RFC008`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc008-payment-data-confirmation.md). Below is a high-level walk-through of this process: | Step | Action | Key artefacts | | ---- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Authorisation Request** | The merchant or PSP sends an OpenID4VP request to the wallet containing a `presentation_definition` that references a _Payment Wallet Attestation_ **and** a base64url-encoded `transaction_data` object (amount, currency, payee). | | 2 | **User Review & Consent** | The wallet displays the human-readable payment details (e.g., € 23.58 to _Merchant XYZ_) and asks the user to approve with a biometric gesture or PIN. | | 3 | **Verifiable Presentation** | The wallet returns a Verifiable Presentation that includes (a) the selected Payment Wallet Attestation (as an SD-JWT VC) and (b) a key-binding JWT whose `transaction_data_hashes` claim proves the user signed the exact payload from step 1. | | 4 | **Verification** | The PSP validates the presentation, checks that the hash of the original `transaction_data` matches the one in the JWT, and ensures the timestamp is recent. | | 5 | **Funds Movement** | Having satisfied SCA, the PSP proceeds with the normal card or account payment, confident that the user explicitly confirmed the transaction details. | #### Example: Transaction Data Payload 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. ```json { "payee": "Merchant XYZ", "currency_amount": { "currency": "EUR", "value": "23.58" }, "recurring_schedule": { "start_date": "2024-11-01", "expiry_date": "2025-10-31", "frequency": 30 } } ``` #### Example: Key-Binding JWT Claims After the user approves, the wallet creates a key-binding JWT. Its claims prove that the user confirmed the specific transaction data. ```json { "nonce": "n-0S6_WzA2Mj", "aud": "https://example.com/verifier", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4", "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"] } ``` ## 6. The Industry Response: Converging Payments and Identity 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. ### 6.1 Parallels with Payment Tokenization A powerful way to understand the potential of [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (VCs) is to compare them to the successful network payment tokenization systems (like [Visa](https://www.corbado.com/blog/visa-passkeys) Token Service or [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/glossary/pan). Instead of sharing raw data (name, DOB, address), the user presents a cryptographically signed credential from a trusted [issuer](https://www.corbado.com/glossary/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. ### 6.2 The Rise of Verifiable Payment Credentials 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**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc), the standards body for secure payments, is actively integrating FIDO standards into the EMV [3-D Secure](https://www.corbado.com/glossary/3d-secure) protocol. This allows prior passkey authentications to be used as a strong signal for frictionless approvals, while also preparing for [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) to serve as a modern, [phishing](https://www.corbado.com/glossary/phishing)-resistant alternative to traditional OTP challenges. There are also ongoing discussions on how [verifiable credentials](https://www.corbado.com/glossary/microcredentials) could be incorporated into these flows in the future. - **Visa** has announced the [**Visa Payment Passkey Service**](https://www.corbado.com/blog/visa-passkeys), which securely binds a FIDO [authenticator](https://www.corbado.com/glossary/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**](https://www.corbado.com/blog/mastercard-passkeys), which leverages its Token Authentication Service (TAS) to replace passwords and OTPs with passkey-based [biometric authentication](https://www.corbado.com/blog/passkeys-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. ## 7. The Regulatory Landscape: Europe as a Catalyst Much of this innovation is being accelerated by strong regulatory tailwinds, particularly from the European Union. ### 7.1 The EUDI Wallet's Role in Strong Customer Authentication (SCA) The EU's [eIDAS 2.0 regulation](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) is not just about providing citizens with a [digital ID](https://www.corbado.com/blog/digital-identity-guide); it explicitly envisions the [EUDI Wallet](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en) 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](https://www.corbado.com/passkeys-for-banking) apps or SMS codes. ### 7.2 Apple's NFC Walled Garden Is Now Open (in Europe) A landmark [antitrust settlement in the EU](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706) has already forced Apple to open its previously closed NFC interface on iPhones. As of [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/faq/is-face-id-passkey) 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](https://www.corbado.com/glossary/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. ## 8. An Issuer's Playbook: A Practical Strategy for Verifiable Payments For payment [issuers](https://www.corbado.com/glossary/issuer) (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. ### Phase 1: Expand Coverage & Secure Payments with Passkeys (Today) The foundation of any future wallet strategy is a secure, widely adopted [native app](https://www.corbado.com/blog/native-app-passkeys). 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](https://www.corbado.com/faq/sca-psd2-importance) (SCA), adopt [PayPal's](https://www.corbado.com/blog/paypal-passkeys) 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. ### Phase 2: Evolve Capabilities with Emerging Tech (Next 24-36 Months) 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](https://www.corbado.com/blog/digital-identity-guide) 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. ### Phase 3: Maintain a Frictionless Benchmark & Monitor Passkey Evolution 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](https://www.corbado.com/blog/paypal-passkeys). 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](https://www.corbado.com/glossary/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. ## 9. Challenges and Future Outlook for VCs in Payments For digital credentials to become integral to payment processes beyond just supporting [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/psd2-passkeys)/SCA in Europe, [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) 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](https://www.corbado.com/glossary/issuer) of payment VCs), and [merchant](https://www.corbado.com/glossary/merchant) [acquirers](https://www.corbado.com/glossary/acquirer) 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](https://www.corbado.com/glossary/issuer) 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](https://www.corbado.com/glossary/attestation), not payment execution. ## 10. Conclusion: A Pragmatic Path Forward for Issuers 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](https://www.corbado.com/blog/native-app-passkeys), using it as a vehicle to deploy passkey-based payments that can rival the frictionless "one-click" standard set by Apple Pay and [PayPal](https://www.corbado.com/blog/paypal-passkeys). 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](https://www.corbado.com/blog/mobile-drivers-license), robust account recovery, and regulatory [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding). 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. ## Frequently Asked Questions ### How do Visa and Mastercard's passkey payment services work differently from verifiable credential payments? Visa's Payment Passkey Service binds a FIDO authenticator to payment credentials to confirm identity and authorize payments in a single frictionless step. Mastercard's Payment Passkey Service uses its Token Authentication Service (TAS) to replace passwords and OTPs with passkey-based biometric authentication integrated with MDES tokenization. Both approaches use established payment rails rather than a new verifiable payment credential standard. ### How does the EUDI Wallet's EWC RFC008 flow satisfy Strong Customer Authentication for online payments? Under EWC RFC008, the merchant sends an OpenID4VP request with a base64url-encoded transaction_data object specifying amount, currency and payee. After biometric or PIN approval, the wallet returns a Verifiable Presentation with a key-binding JWT whose transaction_data_hashes claim proves the user confirmed the exact transaction. The PSP then validates this proof and processes payment through normal card or account rails. ### When should a bank use digital credentials versus passkeys in a payment flow? Digital credentials like mdocs excel at high-assurance identity tasks: KYC onboarding, step-up authentication for high-risk transactions and account recovery for lost devices. Passkeys are the recommended tool for payment authentication itself, providing phishing resistance and a frictionless one-click experience. Adding a credential presentation step to payment confirmation introduces friction that harms conversion rates. ### What are the key differences between Android and iOS for integrating third-party payment wallets? Android supports third-party payment wallets through multiple pathways: the Digital Credentials API via OpenID4VP, a Native Wallet Selector and FIDO CTAP cross-device flows. iOS limits third-party payment wallets to app-to-app deep linking in most regions, with NFC tap-to-pay only available in the EEA since iOS 17.4 (March 2024). iOS provides no native wallet selector for third-party payment apps.