EUDI wallet integration: what to build around your customer platform

A company adding EUDI wallet support rarely needs another standalone identity demo. It needs a wallet interaction to produce a safe, useful result inside a service that already has customer accounts, support processes and operational constraints.

The commissionable project is that integration: the connection between the wallet-facing verifier and the company's application, identity platform and decision workflow. A successful presentation is one input. It is not, by itself, an instruction to create an account, merge two customers or approve an application.

This guide uses an illustrative subscription-service provider with an existing customer identity and access management system, or CIAM, and an onboarding backend. It is a proposed architecture and procurement approach, not a customer case study. Its purpose is to help a company define work an engineering partner can actually deliver and the evidence needed to accept it.

Choose the business transaction before the protocol components

Start with one action: identify a new applicant, verify an attribute for an existing account, or let a returning customer authenticate. These journeys may share infrastructure, but they have different account-binding and recovery requirements.

For the example provider, the first release adds wallet-based identity evidence to a new-customer onboarding journey. The existing account login remains in place. The backend still makes the onboarding decision, and the support team still owns unresolved cases.

Write down what changes for that first release. Which screen offers the wallet option? Which attributes does the backend need? Which existing check does the presentation replace or supplement? What happens when the user has no supported wallet? Which system owns the final decision?

The European Commission describes service providers as organizations requesting wallet data before granting a service. Its current guidance includes registration in the Member State of establishment and information about the intended use and requested data. Treat that organizational work as a dependency in the project plan, with an owner outside the implementation team where necessary. Commission guidance for service providers

Do not turn an architectural article into a universal acceptance deadline. Applicability and national onboarding arrangements need to be established for the actual company and service.

Put a deliberate boundary between verification and your application

A useful starting architecture has three responsibilities: the wallet-facing verifier, an integration layer and the existing business backend.

Customer browser  <---->  Onboarding backend  <---->  CIAM
       |                         |
       |                  Verification adapter
       |                         |
Customer wallet   <---->  Wallet-facing verifier
                                 |
                         Trust configuration

The verifier handles the selected presentation protocol and credential processing. The adapter translates an accepted technical result into the application's vocabulary. The onboarding backend decides whether that result satisfies the business transaction.

This boundary makes replacement and testing easier. A hosted verifier and a self-operated verifier can expose the same internal contract. The onboarding team should not need to understand a vendor-specific response document every time it adds a screen.

For example, an internal result might look like this. It is an illustrative application interface, not an OpenID4VP message:

{
  "verificationRequestId": "vr_example_42",
  "onboardingId": "onboarding_example_17",
  "outcome": "accepted",
  "policyVersion": "onboarding-identity-v1",
  "evidenceReference": "evidence_example_08",
  "evaluatedAt": "2026-09-07T10:00:00Z"
}

Keep the evidence reference opaque and access-controlled. Define separately which attributes are permitted to enter the customer record. Avoid returning the complete presentation to every internal service simply because it is available.

The contractor's deliverable here should be a versioned interface, explicit error outcomes and contract tests against the business backend. A wrapper that forwards an unstructured payload leaves the difficult integration decisions to the client after handover.

Keep wallet evidence separate from account linking

Account linking deserves its own design review. A customer presenting fresh identity evidence is not necessarily authenticated to an existing account that happens to contain a similar name or email address.

For the example provider, begin a verification request from a server-owned onboarding record. Associate the result with that pending transaction, not with whichever browser session receives the callback. If the journey involves an existing account, establish the required authentication to that account before changing its identity association.

Define how duplicate customer records are handled. “We found a similar record” can lead to a support review; it should not silently become “we merged your account.” Decide which identifiers are suitable for the service and jurisdiction, what matching evidence is required and how a mistaken association can be corrected.

Ask the engineering partner to demonstrate a two-browser test. Start different onboarding journeys in two browser sessions, then attempt to exchange or replay their results. Neither journey should acquire the other's evidence. Repeat with a logged-in customer and an unauthenticated applicant.

This is especially valuable work for an external team because the defect can sit between otherwise correct components: a verifier may validate a presentation correctly while the application attaches it to the wrong customer.

Version the trust and interoperability assumptions

“Supports EUDI” is too broad to be an acceptance criterion. Record the target wallet implementations, credential types and formats, presentation profile, verifier release and trust configuration used for the agreed journey.

OpenID4VP 1.0 defines requesting and presenting credentials, with validation and replay-protection requirements. Its protocol success does not define your company's onboarding approval or account-linking policy. Keep the protocol checks and business decision separately observable. OpenID4VP 1.0

The EUDI reference verifier's configuration also exposes concrete integration concerns such as supported formats, client identification and trust material. A reference component is useful implementation material; the project still needs to configure it for the intended ecosystem and operate it in the client's environment. EUDI reference verifier configuration

A practical compatibility record should name versions and test dates, identify which dependencies are under your control, and state what has not been tested. Do not substitute a discussion document or a moving development branch for an agreed production baseline. When a dependency changes, the record tells you which tests must be repeated.

Make registration, certificate provisioning and renewal visible in the delivery plan. The software team can automate technical handling, but it cannot invent an organization's authority to request attributes. Separate “the deployment starts” from “the organization has the required production trust material.”

Design the journey across devices and interruptions

A desktop customer may continue in a phone wallet. A phone customer may switch between browser and wallet. Both can cancel, lose connectivity or return after the request expires.

Specify those states before building the interface. The browser should know whether the request is waiting, completed, cancelled, expired or failed. It should not treat a closed wallet window as evidence that verification succeeded or failed.

Keep completion server-authoritative. A client-side “success” screen should follow a result associated with the correct pending transaction. Retrying a completion callback should return the existing outcome or a defined error, not create another customer.

For an initial rollout, retain a deliberate alternative journey for users who cannot complete the wallet flow. Name its owner and security requirements. An unplanned fallback that skips the checks the wallet was meant to provide is a new vulnerability, not a usability improvement.

Support staff need explanations they can act on: request expired, unsupported evidence, identity association requires review. They do not need cryptographic payloads pasted into a ticket. Give the support interface a correlation reference and bounded diagnostic details instead.

Make failure behavior part of the delivery contract

A contractor brief should include an acceptance pack, not just a list of endpoints. For the example onboarding integration, ask for demonstrations of these cases:

1. Duplicate completion: two workers process the same result concurrently. The onboarding transition happens once.
2. Wrong transaction: a valid response from one journey is submitted to another. No account is linked or approved.
3. Expired request: the customer returns after the pending request expires. The UI offers a fresh start without reusing the old result.
4. Unaccepted evidence: a technically valid credential fails the configured issuer or attribute policy. The result explains the policy rejection without claiming a cryptographic failure.
5. Trust dependency unavailable: the documented outage policy applies. The system does not silently bypass the check.
6. Deployment during a journey: an in-flight request survives the supported rollout path, or ends with an understandable retry instruction.
7. Telemetry inspection: logs, traces and analytics contain only the agreed operational fields, including when parsing or validation fails.

Test outcomes should connect to a specific policy and component version. Collect synthetic fixtures, setup instructions and reproducible results in the client's repository. A video of the happy path is useful communication, but weak handover evidence.

Decide what to buy and what to commission

A managed verifier can reduce the protocol and infrastructure work a company operates. Evaluate it against the exact credential and wallet combinations you need, its trust-management model, deployment constraints, data handling and ability to export useful evidence. Require a demonstration against your acceptance pack rather than relying on a feature label.

A self-operated component can offer more deployment control, but makes patching, key handling, availability and compatibility testing part of your operating responsibilities. Assign those responsibilities before deciding that a reference implementation makes the project inexpensive.

In either approach, the integration work remains: customer-record mapping, request lifecycle, account binding, failure handling, support tooling and release coordination. These are sensible boundaries for a specialist engineering contract. The goal is a maintainable connection to the business, not ownership of every protocol implementation.

An engineering partner should hand over source code, infrastructure definitions, configuration guidance, automated tests, a dependency inventory and an operations runbook. The client should own its production accounts and credentials, policy decisions and access to the repository from the beginning.

Commission a first release with measurable boundaries

A useful first statement of work names one journey, its required attributes, supported wallet combinations, the current CIAM and onboarding interfaces, deployment ownership and acceptance evidence. It should also list exclusions: for example, account recovery or additional markets may be later work rather than implied features.

Start with a short discovery outcome: a trust and data-flow map, a compatibility baseline, an internal interface proposal and a register of unresolved dependencies. Then implement one complete path through the real staging environment. Expand only after the business integration and rejection cases work together.

Estimate after those boundaries are visible. A timeline that ignores access to the customer backend, production trust material or an undecided account-linking policy hides the largest delivery risks.

If your company needs to add wallet verification to an existing platform, our identity and EUDI engineering practice can work with you on that integration. Bring the current system diagram, the customer journey and the decision the wallet should support. Let's scope what we can build together.

For the other side of the exchange, read how to scope credential issuance from enterprise records.