As we move toward the broad implementation of European Digital Identity (EUDI) Wallets in 2026, the strategic focus for financial institutions shifts from basic regulatory compliance to the quality of the user experience. For years, digital identity interactions have relied on two primary methods: scanning a QR code or performing a manual "app-switch." While these have served as important stepping stones, they introduce significant friction—forcing users to abandon their current context and navigate a multi-step approval journey that can lead to higher drop-off rates and confusion. Moreover, as highlighted in the Architecture and Reference Framework (ARF) DC API Discussion Paper discussion, these legacy flows can expose organizations to security risks like session fixation and relay attacks.
The Digital Credentials (DC) API is the foundational technology designed to solve these challenges. This emerging W3C standard enables a native, system-level bridge between the browser and the wallet, allowing for a seamless "bottom-sheet" interaction that keeps the user within the flow of their transaction. For product managers and IT architects, understanding this API is no longer optional; it is the key to delivering secure, high-assurance processes - from KYC onboarding to Strong Customer Authentication (SCA) - with the speed and convenience consumers expect from modern banking.
In this guide, you will learn how the DC API works, why it is essential for mitigating the security vulnerabilities of QR-based flows, and how it streamlines complex cross-device interactions. As early pioneers in this space, we at Lissi have already integrated the DC API into our production-grade infrastructure, a milestone that was pivotal to our success in the German Wallet Challenge. By sharing our insights from collaborations with global leaders like Google and Mastercard, we aim to provide you with the roadmap needed to transition your institution from the "QR code era" to a native, credential-centric future.
Why QR Codes Aren’t Enough for Banking
In the early pilots of the EUDI Wallet, most interactions rely on cross-device flows - typically a user sitting at a laptop, scanning a QR code with their phone to trigger a wallet action.
While this is a familiar behavior, the ARF discussion paper highlights that for high-stakes banking processes, this "QR code era" introduces specific, systemic challenges:
- The Security Vulnerability (Relay Attacks): QR codes are essentially static triggers. In a "relay attack," a malicious actor can capture a legitimate QR code and present it to an unsuspecting user on a different device. Because the browser and the wallet aren't natively "aware" of each other’s session, it is difficult to cryptographically prove that the person scanning the code is the same person who initiated the transaction.
- The "Context Switch" Friction: Forcing a user to switch from their browser to a separate wallet app - and then back again - is a "conversion killer." In a mobile banking environment, every additional step or "app-hop" increases the risk of the user abandoning the process, particularly during sensitive flows like Strong Customer Authentication (SCA).
- The Discovery Problem: With the expected rollout of over 30 national and private wallets across Europe, users face a "selection fatigue." If a bank requests a specific attribute such as an IBAN credential, the user shouldn't have to guess which of their potentially multiple wallets contains the correct, up-to-date credential.
For a bank, a failed identification flow isn't just a UX issue; it’s a lost customer and a potential security liability. We need a "session-bound" interaction where the browser and the wallet communicate directly through a trusted, system-level mediator. By addressing these friction points, the DC API doesn't just make the flow "nicer" - it makes it robust enough for the high-assurance requirements of the financial sector.
In our direct conversations with the teams writing these standards, it’s clear that the goal is to move away from "unmanaged" custom URI schemes (which can be hijacked by malicious apps) toward the managed security of the DC API. This is why we have prioritized this integration in our EUDI-Wallet Connector - allowing our clients to bypass the technical debt of legacy QR flows and move straight to a native experience.
Introducing the DC API: The "Native" Solution
To solve the friction and security gaps of the "QR code era," the industry is moving toward a native interaction model. The Digital Credentials (DC) API serves as this critical bridge, allowing a web browser to communicate directly with the operating system to find and present identity credentials.
.png)
Unlike traditional methods that redirect users away from their current task, the DC API introduces a "bottom-sheet" experience. When a bank or service provider requests information, a native UI element slides up over the current screen, managed entirely by the device's operating system. This allows the user to stay within the context of the transaction, providing a smoother, more intuitive approval journey.
Key Functional Breakthroughs
- Credential-Centric Selection: Instead of the user having to remember which wallet app holds their specific credential, the browser and OS automatically search all installed wallets. They then present the user with a list of matching attestations - such as a IBAN or similar payment credentials for SCA purposes—to choose from.
- Protocol Agility: The API acts as a unified entry point that can support multiple standardized protocols, including OpenID4VP and ISO 18013-7 (mdoc) depending on the OS plattform. This ensures that your infrastructure remains compatible with the 30+ wallet variants expected across the EU.
- Seamless Cross-Device Support: The DC API isn't just for same-device flows. It enables a secure "tunnel" between a browser on a laptop and a wallet on a nearby phone, utilizing the same underlying technology as Passkeys (WebAuthn) to ensure a familiar and high-security experience.
While the W3C standard is still being finalized, the momentum is undeniable. Major players like Google have already moved forward with production-grade implementations in Chrome and Android. As a bank, adopting a "wait-and-see" approach carries a hidden cost: the risk of building legacy infrastructure that will need an expensive overhaul as soon as native OS support becomes the de facto standard for high-assurance flows.
Strategic Benefits for Financial Institutions: Security & Seamless UX
For financial institutions, the transition to the DC API is not just a technical upgrade; it is a strategic move to resolve the inherent tension between high-security requirements and the demand for a frictionless user experience. As banks prepare to meet the July 2027 mandate for EUDI Wallet acceptance posed by the AML Regulation, the DC API offers three critical advantages:
1. Security by Design: Eliminating the "Man-in-the-Middle"
Traditional QR-based or URL-redirection flows are vulnerable because they rely on the user to act as the "bridge" between two disconnected sessions. This creates an opening for relay attacks and session fixation. The DC API moves the interaction into a system-level mediator (the OS).
- Origin Verification: The OS cryptographically verifies the origin of the request, ensuring that the credential is only presented to the legitimate, intended website.
- Session Binding: Because the OS manages the channel, the presentation of the credential is bound to the specific browser session, making it nearly impossible for a remote attacker to "hijack" the flow.
2. Frictionless SCA for all PSD2 Processes
While initial discussions often focus on e-commerce checkouts, the DC API’s impact is far broader. It is designed to streamline Strong Customer Authentication (SCA) across all regulated banking processes—including high-value transfers, account access, and mandate approvals.
By using what the latest technical specifications (TS12) refer to as an "SCA credential," banks can trigger a high-assurance approval directly through the OS bottom sheet. This replaces the need for SMS-OTPs making transactions faster and more secure without sacrificing the "High" Level of Assurance required under eIDAS 2.0.
3. The UX Challenge: Balancing Speed with Trust
Moving the interaction to an OS-controlled "bottom sheet" significantly reduces the "clicks-to-completion." However, we also recognize that this also introduces a new challenge: Information Density.
In a smaller, native UI managed by the operating system, banks must carefully manage how they display critical information:
- Trust Marks: How can the user quickly verify that the requester is a certified financial institution?
- Purpose of Request: Clearly stating why specific attributes (like your IBAN or an account balance) are being requested in a limited space.
- Attribute Transparency: Ensuring the user knows exactly what data is being shared before they authenticate with biometrics.
The goal is to move the user from "Where is my wallet?" to "I trust this request." While the DC API simplifies the journey, the quality of the integration determines whether the user feels safe or rushed. This is why we focus heavily on the "Approval Journey" design within the Lissi Connector.
Lissi: Turning Standards into Reality
At Lissi, our conviction has always been that for the EUDI Wallet to succeed in highly regulated sectors, the technology must be invisible, secure, and integrated into the tools users already use—their browsers and operating systems. We didn't wait for the final version of the W3C standards to begin this journey; we started implementing the DC API as soon as the first drafts and experimental flags became available.
This proactive approach was a defining factor in our success during the German Wallet Challenge. By integrating the DC API into both our wallet and our connector early on, we were able to demonstrate a level of UX fluidity and security that set our solution apart. It proved that "native" flows weren't just a future concept but a functional reality that could meet the rigorous demands of national regulators.
Our leadership in this space is strengthened by continuous collaboration with the pioneers of the digital economy:
- Partnership with Mastercard: We are currently collaborating with Mastercard to explore how the Digital Credentials API can be combined with Digital Payment Credentials (DPC) standard. While the DC API provides the native OS‑level invocation of credentials, DPC complements it by orchestrating the end‑to‑end payment and authentication experience—ensuring a consistent, high‑quality UX across issuers, wallets, and platforms, fully aligned with PSD2 and future PSD3 requirements.
- WE Build Large-Scale Pilot: In a workshop organised by Visa and Google, we recently presented a working demo co‑developed with Mastercard. This demonstration showcased how DC API‑based credential requests can be orchestrated within payment and approval flows, highlighting the role of both native OS interactions and payment‑grade experience orchestration.
Direct Influence on Standards: While we focus on implementation, we maintain a direct line of communication with the teams writing the standards. This ensures that the Lissi Connector is built with an insider’s understanding of the roadmap, translating technical shifts into ready-to-use features for our clients.
Navigating the 2026 Roadmap: Technical & Regulatory Reality
For financial institutions, the next 12 to 18 months represent a critical implementation window. While the progress of the DC API is rapid, it is important to understand the current landscape to manage your deployment roadmap effectively.
The Multi-Platform Reality: Currently, the most robust support for the DC API exists within the Android and Chrome ecosystem, where the "bottom-sheet" experience is already live for early adopters. The situation regarding iOS and Safari remains a topic of active discussion. Apple has historically prioritized its own proprietary wallet interfaces; however, we expect the eIDAS Coordination Group to address these cross-platform interoperability gaps in the coming months. As a leader in this space, we provide our clients with the flexibility to support native flows where available while maintaining reliable fallbacks for other platforms.
The ARF Topic F & Production Timelines: The Architecture and Reference Framework (ARF) identifies the DC API as a key discussion topic for remote presentation. While the standard is maturing, the clock is ticking for banks. With the 2027 deadline for mandatory wallet acceptance approaching, and typical banking IT cycles lasting 12 to 18 months, the time to begin integration is now. Waiting for a "finalized" standard often means entering the market with legacy technology on day one.
Conclusion: Future-Proofing your Digital Identity Strategy
The transition from the "QR code era" to a native, credential-centric future is inevitable. For product managers, innovation leads and payment experts, the question is no longer whether to support these flows, but how to do so with the lowest risk and the highest reliability.
Building and maintaining a custom integration for every evolving OS-level API across 30+ national wallets is a monumental task that diverts resources from your core business as we described here in more detail. This is why we developed the Lissi EUDI-Wallet Connector.
By choosing a professional, production-grade component, your institution benefits from:
- Faster Time-to-Market: Skip the R&D phase and deploy a working DC API integration in weeks, not years.
- Reduced Regulatory Risk: Stay aligned with the latest ARF requirements and eIDAS 2.0 implementing acts with proactive updates from our side.
- Operational Excellence: Focus on your specific banking use cases while we provide the underlying "engine" backed by 24/7 SLAs and enterprise support.
Don't let your digital identity strategy be held back by the friction of the past. Contact us today for a demo of the DC API in action and learn how our Starter Program can help you lead the way in the EUDI Wallet ecosystem.
.png)



.png)
.png)