The EUDI Wallet & Payments: eIDAS 2.0, SCA & Verifiable Credentials
The European Digital Identity Wallet is a government-issued mobile wallet that every EU member state must offer its citizens by the end of 2026 — and that banks and payment service providers must accept for strong customer authentication by the end of 2027. This guide covers the legal timeline, the credential technology stack (SD-JWT VC, mdoc, OID4VCI/OID4VP), and exactly how a PSD2 SCA payment authentication runs through the wallet.
What the EUDI Wallet is
Regulation (EU) 2024/1183 — eIDAS 2.0, in force since May 2024 — obliges every member state to provide at least one certified EU Digital Identity Wallet to citizens, residents, and businesses. The wallet is a mobile app backed by certified secure hardware that can:
- Store and present credentials — a government-issued Person Identification Data (PID) credential plus attestations from other issuers: driving licences, diplomas, IBANs, payment credentials.
- Identify and authenticate the holder to online services at Level of Assurance High — including strong customer authentication for payments under PSD2 Article 97.
- Create qualified electronic signatures with the same legal effect as a handwritten signature.
The wallet is disclosure-minimising by design: a verifier asks for specific attributes ("over 18", "this IBAN belongs to the holder") and the wallet presents only those, under selective disclosure, with the holder's approval on-device.
The timeline that matters to payments
| Date | Milestone | Impact |
|---|---|---|
| May 2024 | eIDAS 2.0 in force | Legal framework set; Architecture & Reference Framework (ARF) iterating on eudi.dev. |
| Nov–Dec 2024 | Implementing acts adopted | Technical specifications for PID, wallet certification, and protocols become binding. |
| End of 2026 | Every member state must offer at least one certified wallet | Wallets reach consumers at scale; public-sector services must accept them. |
| End of 2027 | Regulated private sectors must accept the wallet | Banks, payment institutions, and e-money issuers that are required to apply SCA or perform KYC must accept EUDI Wallet authentication. This is the deadline that puts the wallet on every EU issuer's and PSP's roadmap. |
The technology stack
The wallet mandates specific credential formats and exchange protocols, profiled together by the High Assurance Interoperability Profile (HAIP):
| Layer | Standard | Role |
|---|---|---|
| Credential format | SD-JWT VC | Selective-disclosure JWT verifiable credentials — the primary remote-presentation format. Each attribute is individually disclosable; holder binding is proven with a Key Binding JWT signed by the wallet's hardware key. |
| Credential format | mdoc (ISO/IEC 18013-5) | The mobile-document format from mobile driving licences — used for proximity presentations and supported remotely. Device binding via the signed SessionTranscript. |
| Issuance protocol | OID4VCI | OpenID for Verifiable Credential Issuance — how an issuer (government PID provider, bank issuing a payment attestation) delivers a credential into the wallet. Built on OAuth 2.0. |
| Presentation protocol | OID4VP | OpenID for Verifiable Presentations — how a verifier requests attributes and the wallet presents them, same-device or cross-device (QR code + phone). |
| Key storage | WSCD | Wallet Secure Cryptographic Device — certified secure element / HSM-backed keystore holding the wallet's binding keys. The reason wallet authentication can claim possession-factor quality comparable to a chip card. |
If you work with EMV, the analogy is close: the credential is the card application, OID4VP is the terminal kernel asking for data, the Key Binding JWT is the cryptogram, and the WSCD is the secure element.
How SCA works through the wallet
PSD2 Article 97 requires two independent factors and — for remote payments — dynamic linking: the authentication code must be bound to the specific amount and payee. The ARF maps this onto wallet mechanics directly:
- Factors — possession is the WSCD-bound key (something you have); the wallet unlock (PIN or biometric) supplies knowledge or inherence.
- Dynamic linking — the verifier includes the transactional data (amount, currency, payee) in the OID4VP presentation request. The wallet displays it to the holder and includes it in the signature it creates for device binding — inside the Key Binding JWT for SD-JWT VC, or the SessionTranscript for mdoc. The resulting signature is an authentication code cryptographically bound to that exact amount and payee.
- Replay protection — the verifier's nonce is signed along with the transactional data, so a presentation cannot be replayed against a different transaction.
A typical e-commerce authentication runs: merchant/PSP triggers the issuer's verifier → OID4VP request (attributes + transactional data) → wallet shows amount and payee, holder confirms with biometric → wallet returns the signed presentation → issuer verifies signature, nonce, and transaction binding → authorisation proceeds. In 3-D Secure terms, the wallet can serve as the challenge method inside the issuer's ACS — compare the flow in the 3DS2 AReq/ARes decoder and the 3-D Secure guide.
Payment-relevant use cases
SCA for Cards & Account Payments
The mandated use case: wallet-based authentication replacing or complementing banking-app push, SMS OTP, and hardware tokens for PSD2 SCA — for card payments (via the issuer's ACS) and account-to-account payments (via the ASPSP). Deadline-driven: regulated PSPs must accept it by end-2027.
KYC & Account Opening
PID presentation at Level of Assurance High replaces document upload + selfie video for bank onboarding. Attribute-level disclosure means a PSP can request exactly the attributes its CDD process needs. Same end-2027 acceptance obligation.
IBAN & Account Attestations
Banks as attestation issuers: an electronic attestation that "this IBAN belongs to this holder" — useful for payee verification, payroll setup, and direct-debit mandates. Pairs naturally with SEPA Verification of Payee. Check formats with the IBAN validator.
Age & Attribute Checks at Checkout
Selective disclosure of "over 18" or residency without revealing identity — for regulated goods, gambling deposits, and age-gated subscriptions, combined with the payment in one wallet interaction.
Qualified Signatures for Mandates
Qualified electronic signatures from the wallet carry handwritten-equivalent legal effect — signing credit agreements, SEPA mandates, and high-value payment orders without a separate QES provider.
Agentic Payments & Delegation
The same verifiable-credential machinery underpins agent-payment mandates: Google's AP2 protocol uses verifiable digital credentials to prove a human authorised an AI agent's purchase. EMVCo's Digital Identity and Payments Task Force is working the same seam — wallet-grade identity meeting card payments. See the x402 guide for the machine-payment side.
What payment engineers should do about it
| If you are… | What changes | When |
|---|---|---|
| An EU card issuer / ACS operator | Add wallet authentication as a challenge method: act as an OID4VP verifier, request transactional data, verify Key Binding JWTs. Fits alongside existing app-based out-of-band challenges. | Design 2026, mandatory acceptance end-2027 |
| A PSP / acquirer | Little direct change — SCA remains the issuer's job — but checkout UX will grow wallet-redirect flows, and merchant onboarding (KYB) gains wallet-based options. | Watch 2026 pilots |
| An ASPSP (open banking) | Wallet becomes an accepted SCA method for account access and payment initiation — relevant to every redirect and decoupled flow in the open banking guide. | End-2027 |
| Building fraud / risk systems | Wallet presentations give you signed, government-anchored identity signals with exact transaction binding — a materially stronger signal than device fingerprints. | As adoption grows 2027+ |
Reality check: the end-2026 deadline is for wallets to be offered, not adopted. Member-state implementations, certification schemes, and the ARF are still moving — treat exact protocol details (ARF is on its 2.x iterations) as fluid and pin your builds to the implementing acts and HAIP, not to blog posts.
Related reading & tools
3-D Secure Guide · 3DS2 AReq/ARes Decoder · Open Banking Guide · x402 & Machine Payments · IBAN Validator · Tokenization Guide