Skip to main content

WE BUILD Consortium: EUDI Wallet and European Business Wallet Large Scale Pilot

EU Large-Scale PilotOngoing

WE BUILD is one of the official European Large-Scale Pilots for the EU Digital Identity Wallet and European Business Wallets, bringing together 180+ public authorities and private companies across 27 countries. iGrant.io is a named beneficiary contributing across several WE BUILD workpackages, from architecture and conformance through to wallet provisioning and business use case delivery. This page is the home for that work, and it sits alongside our wider EUDI Wallet pilots and production deployments.

Deliverables​

This is the home for iGrant.io's WE BUILD deliverables, and it grows as the pilot progresses. Further deliverables, including Business Registry workflows (Legal Person Identification Data issuance), document signing and Qualified EAA issuance, will be added as they land.

Architecture workpackage​

WorkpackageOngoing

The Architecture workpackage defines the common blueprint, conformance specifications and test tooling that every WE BUILD wallet and service is built and tested against. iGrant.io contributes here on three fronts:

  • Architecture Blueprint Team. iGrant.io is part of the team shaping the WE BUILD reference architecture for the EU Digital Identity Wallet and European Business Wallets.
  • Conformance specifications. iGrant.io contributed a significant part of the conformance specifications that define what a conformant wallet or service must do.
  • Interoperability Test Bed (ITB). Together with several partner companies, led by the University of the Aegean, iGrant.io helped build the ITB that WE BUILD uses to test wallets and services against those specifications.

The Organisation Wallet Suite is listed as the first conformant business wallet in the WE BUILD Conformance Overview.

eReceipts (verifiable receipts)​

Use caseIn progress

eReceipts are trusted, verifiable purchase receipts issued straight into a European Business Wallet, taking EUDI Wallet payments from the consumer to the company. Today a business purchase still ends in a paper or PDF receipt that someone keys into an accounting system by hand, and a lost receipt can put a VAT claim at risk. eReceipts replace that chain with two wallets that work together.

How it works:

  1. An employee pays from a company account or card using their EUDI Wallet, authorised with Strong Customer Authentication (SCA).
  2. The seller's business wallet issues the receipt as a verifiable credential directly into the buyer's European Business Wallet.
  3. Buyer and seller hold the same signed record, so it books into accounting automatically.
  4. A tax authority can verify the receipt and reconcile input VAT without manual data entry.

Because the receipt is a selectively disclosable credential, the holder shares only the fields a given service needs, for example proof of purchase for an expense report or a warranty claim. This takes forward the consumer e-receipt flow first demonstrated in the EWC Large-Scale Pilot, described under EUDI Wallet Pilots and Deployments, and extends it to business-to-business payments.

Watch the full demo on YouTube

Read the background in Trusted eReceipts for B2B payments.

Account onboarding and account-to-account payments​

Use caseIn progressEvent:GDC26 Geneva, September 2026Use cases:PaymentsBuilding blocks:WalletsCredentialsIssuersVerifiersFocus areas:StandardsGoals:InteroperabilityRegions:EuropeFormat:Demo

Pay by bank with the EUDI Wallet. Open a bank account with the wallet, receive a payment credential from the bank and pay a shop straight from that account by confirming the amount in the wallet. No forms, no passwords and no card numbers. iGrant.io and Bank iD (Czechia) showed this flow at the Global Digital Collaboration Conference (GDC26) in Geneva in September 2026. The two-minute video below is the demo as shown there.

Account provisioning and account-to-account payment (WE BUILD WP3 Consumer Banking, PA1, and Consumer Payments, PA2 scenario A2) takes the consumer payment flow from the EWC pilot one step further. In EWC, a bank linked an existing account to the EUDI Wallet with a card-based Payment Wallet Attestation. In WE BUILD, the bank opens the account with the wallet in the first place, provisions a Bank Account Key into it, and the customer pays account-to-account at a merchant by confirming the transaction in the wallet, with the merchant reaching the wallet through the W3C Digital Credentials API (DC API). The merchant and the verification run on the iGrant.io Organisation Wallet Suite.

Watch the full demo on YouTube

How it works:

  1. The customer opens a bank account with the EUDI Wallet: no forms and no passwords. The wallet presents the person identification data (PID), the bank performs identity matching and opens the account.
  2. The bank issues a Bank Account Key into the wallet over OpenID4VCI: a payment credential bound to the account that carries the IBAN, BIC, currency and issuing authority. In the WE BUILD specifications this is the SCA-IBAN attestation.
  3. At the merchant's checkout the customer chooses account-based payment. The shop calls the wallet through the DC API, the customer reviews the amount and confirms with the Bank Account Key, and the payment is authorised straight from the bank account.

For developers. The shop calls navigator.credentials.get() from the page and the browser and operating system hand an OpenID4VP 1.0 request to the EUDI Wallet: no redirect, no app link and no QR code on the same device. The request carries a DCQL query for the Bank Account Key and a transaction_data object in the ARF Technical Specification 12 (TS12) payment schema with the amount and the payee. The wallet returns an SD-JWT presentation with a Key Binding JWT over the nonce, the verifier and the transaction data hash. This is the dynamic linking that Strong Customer Authentication (SCA) under PSD2 requires: any change to the amount or the payee breaks the hash. The Organisation Wallet Suite checks the issuer signature, the trust list status and the hash, and the shop, or a payment initiation service provider on its behalf, sends the payment body and the presentation to the bank in one Signed Payment Request. This is the flow described in the DC API overview, the step-by-step guide Verify credentials with the DC API on Android (Chrome) and the DCQL overview.

It works on Android with Chrome 141 or later. It does not work on iOS yet: Safari, and therefore every browser on iOS, implements only ISO/IEC 18013-7 Annex C over the DC API and does not offer OpenID4VP, so a Bank Account Key (an SD-JWT credential presented over OpenID4VP) cannot be requested through the DC API on iPhone or iPad; see DC API on iOS (Safari). On iOS the merchant's standard OpenID4VP flow (QR code or app link) remains the way to pay.

The same checkout also accepts the card-based flow from EWC, so a merchant integrates once and takes both instruments through one strong customer authentication (SCA) pattern. Combined with eReceipts, this closes the loop from account opening to payment to a verifiable receipt in the buyer's wallet. The scenarios are piloted cross-border between Czechia and Greece.

Try it yourself on an Android phone with Chrome: open an account at the Bank iD onboarding demo with your EUDI Wallet, then pay account-to-account at the WE BUILD Shop. The building blocks are documented under Payment Wallet Attestation, Payment Data Confirmation and verification with the DC API on Android.