EUDI Wallet Integration

Connect to the European digital wallet ecosystem

Build EUDI Wallet functions into your own systems with an SDK or a hosted service.

Contact usLearn more

Any relying party

  • Government
  • Bank
  • Telco
  • University
  • Employer
  • Marketplace
Request for data
Data sharing

TrustID Solutions

  • SDK
  • Gateway
  • Connector
  • App
Approval
Attestations

EU national wallets

  • HU
  • DE
  • RO
  • FR
  • EU
  • 18+Proof of Age
  • Driving Licence
  • Diploma
  • Personal ID
  • Further attestations

  • One connection

    Access EU national wallets

  • Flexible integration

    SDK · Gateway · Connector

  • Citizen-controlled data

    The citizen chooses what to share

Supported wallets

One integration, and every wallet on the list works with your service. We test each of them and keep the list current.

  • DÁP

    Production

    Hungary · Digital Citizenship Programme

    Tested flows

    PID presentation, age verification, mandate check

  • EUDI Reference Wallet

    Verified

    European Commission · ARF reference implementation

    Tested flows

    PID presentation, SD-JWT VC and mdoc flows

Your users carry a wallet that isn’t on the list? Send us the wallet and the credential you need. Tell us your timeline and we’ll tell you ours.

Contact us

Four ways to connect

The verification is the same in every model: building the request, handling the wallet response, checking signatures and trust lists. What changes is how much of it runs on your side. Pick the model that matches your stack and your capacity for operating infrastructure.

  1. 01SDK

    The entire service runs in your own environment. TrustID delivers the software (an SDK implemented in Java that you integrate into your own system) and the know-how as support and consulting.

    Typical use

    • Financial institutions
    • Insurers
    • Brokers
    • Large service providers
    • Regulated data handling
    Client-side development need
    Full integration; the client also handles configuration and certificate management.
    Best fit
    Java-based stack, own front end, and you both want to and can operate the service environment yourself. Strict internal security or compliance requirements are easiest to satisfy here.

  2. 02Gateway

    You keep your own interface and backend, which reach the SDK through a gateway hosted by you or by TrustID. The SDK itself is operated by TrustID.

    Typical use

    • Private healthcare
    • In-house dev team
    • Existing customer portal
    • Mid-market service provider
    Client-side development need
    Server-to-server call; if the client hosts the Gateway, configuration and certificate management are the client’s responsibility too.
    Best fit
    Own front end on a stack that isn’t Java, or infrastructure and security restrictions that rule out running the SDK yourself. Hosting the Gateway on your side keeps a high security or compliance bar within your own perimeter.

  3. 03VeriFlow Connector (OIDC)

    A standards-based OIDC login. TrustID provides the screens and the service for identification and attribute-request flows, and hosts the gateway and the SDK behind them unless you ask otherwise.

    Typical use

    • Age verification
    • Booking system
    • Webshop
    • Customer portal
    • Hospitality check-in
    Client-side development need
    Integrating the provided components and handling the redirect.
    Best fit
    Own front end on any stack, an existing authentication server, and no intention of running wallet-side infrastructure.

  4. 04VeriFlow App

    A responsive web app provided by TrustID, with no system integration required on your side. An admin site lets you customise what each check asks for.

    Typical use

    • Shop & checkout
    • Reception
    • Event check-in
    • On-site inspection
    Client-side development need
    Not required.
    Best fit
    No own front end, no development capacity and no infrastructure of your own to operate, on any technology stack. Typically used at physical locations.

Division of operational responsibility

All four tasks are carried out in every model. What changes is which side does them. The Wallet itself sits outside this split: it’s the source of trusted identification that every model ultimately reaches.

  • 01SDK

    Your own app or website
    Client
    Identification & consent screens
    Client
    Gateway
    Not required
    Verifier SDK
    On your premiseslicensed from TrustID

  • 02Gateway

    Your own app or website
    Client
    Identification & consent screens
    Clientyour own branding
    Gateway
    TrustIDorClientdepending on need
    Verifier SDK
    TrustID

  • 03VeriFlow Connector (OIDC)

    Your own app or website
    Clientstandard OIDC client
    Identification & consent screens
    TrustIDVeriFlow interface
    Gateway
    TrustIDtypically*
    Verifier SDK
    TrustID

  • 04VeriFlow App

    Your own app or website
    TrustIDVeriFlow App
    Identification & consent screens
    TrustIDVeriFlow interface
    Gateway
    TrustID
    Verifier SDK
    TrustID
  • Client responsibility
  • TrustID’s service
  • Not required

* If needed, the Gateway can also be hosted by the client.

Not sure which model fits? Tell us what your stack looks like and where the check has to happen, and we’ll tell you which of the four we would start with.

Contact us

Looking for the bigger picture? Our EUDI Wallet Portal covers the ecosystem itself: what the wallet is, who issues credentials, how the trust model works and where the standards are heading. It is open to everyone, with no sign-up and nothing to buy.

Visit the EUDI Wallet Portal