Get your business ready for digital wallets

Start with the decision your service needs to make. Then work out what a wallet could prove, which evidence you would trust and how a customer could complete the same task without one. Buying an integration comes after those decisions.

What are you getting ready for?

A digital identity wallet holds credentials that a person can present to another organisation. A credential is a signed statement from an issuer: who someone is, for example, or whether they meet an age threshold. The organisation using that statement is the relying party. The software checking it is a verifier. Your organisation may buy that software without becoming the issuer or wallet provider.

This matters because a successful identity check is only part of a business decision. A valid name does not establish that someone may operate a company account. An age result does not establish that a purchase meets every other applicable rule. Define what you need to know and keep your service's eligibility decision separate from the technical verification result.

The European Commission's service-provider guide explains the relying-party role, requested attributes and registration. Treat it as your starting map; have the person responsible for compliance establish which obligations apply to your organisation and when. A general EU timetable is not an Irish launch announcement or a universal deadline for every small business.

1. Choose one transaction

A useful first use case has a clear start and finish. “Improve identity” is too broad. “Let an eligible customer demonstrate an age threshold at checkout” gives product, privacy and engineering teams something they can test. Write down the current journey before drawing the wallet version: the information requested, the time it takes, the people who abandon it and the support work it creates.

Pick a transaction where verified attributes could remove a real burden. Do not ask for a full identity simply because the wallet can supply one. If the service needs a professional qualification, a name and birth date may not answer its question. If it only needs an age threshold, collecting an address creates an additional data-handling problem without helping the decision.

Service decision	Candidate evidence	Question before a pilot
Is this customer above a threshold?	A signed age result	Is the required credential actually available?
Does this person hold a qualification?	An attestation from a trusted issuer	Which issuers and qualifications are accepted?
Can this person act for a business?	Identity plus evidence of authority	How will authority, scope and expiry be checked?

These are design examples, not claims that each credential is currently issued by Ireland's wallet. Record availability as a dependency and name the evidence needed to close it. A supplier's roadmap is useful planning input, but it should not become an assumption hidden in your release date.

2. Make an attribute map

An attribute is an individual fact such as a name, address or over-18 result. For every requested attribute, record the purpose, who receives it and how long you need it. Distinguish the data used to complete the transaction from the smaller record needed to explain the decision afterwards. Ask whether the business needs the full value or simply an answer to a question.

For example, your proposed audit record might contain the check time, the accepted credential type and the outcome. That does not automatically justify retaining the complete credential or identity document. Work through the legal and operational requirements with your privacy lead. A consent screen in the wallet does not decide your organisation's lawful basis or retention policy for it.

Draw the whole route: customer device, verifier, gateway, your application, support console, logs and backups. Mark where personal information appears. This often exposes a practical weakness that the polished demonstration omits: a developer logging an entire verification response or a support dashboard displaying more information than the operator needs.

3. Decide what makes evidence acceptable

Checking a digital signature is not the same as deciding to trust its issuer. Your verification policy needs to specify accepted issuers, credential types, freshness and any applicable status checks. It also needs to connect the presentation to the right customer interaction. A result from an earlier session should not silently authorise a different transaction.

Ask your technical team to explain the result in business terms. Does “verified” mean that a signature was valid, that the issuer was trusted for this attribute, that the presentation matched the current request, or that your complete business policy passed? Those are different assertions. Keep them distinguishable in the system and in supplier reporting.

Have the supplier demonstrate refusal as well as acceptance. What happens with an unsupported credential, an expired request, a cancelled presentation or an unavailable dependency? The useful answer is a safe outcome with a clear explanation and a route forward. An unexplained red cross is likely to become a support ticket.

4. Choose your integration approach

You can build against wallet specifications, buy a hosted verifier or use a gateway that handles multiple wallet connections. These choices trade engineering control against supplier dependency. Compare the complete service, not just the number of lines in an API example. Who maintains trust information, monitors failures, updates supported formats and responds when a wallet changes?

A hosted service can shorten initial development, but you still own your user journey, requested data, access decisions and customer support. An internal implementation gives more control only if your team has time to operate it. A hybrid approach can work, but make its responsibilities explicit rather than assuming the two sides cover each other.

Read our gateway and verifier guide before comparing quotes. Request a written responsibility split, sample result schema, retention settings, export options and an explanation of what remains to be done before production. A working test connection is one piece of that evidence.

5. Design for people who cannot finish

Some customers will not have a compatible phone, the right credential or a wallet they want to use. Others will be on the same phone as your website and unable to scan a QR code shown on that screen. Design and test the appropriate app-link journey as well as the desktop-to-phone journey.

Cancellation should return people to an understandable next step. A retry should not create duplicate accounts or erase an application they have already completed. Give people an alternative route and tell them what they need before they start. Test zoom, screen readers, keyboard access and slow devices with the same care as the demonstration device.

Recovery deserves its own exercise. If someone loses their phone after opening an account, what evidence will your service accept to restore access? Do not let account recovery undermine the assurance of the original enrolment. Link the design to your accessibility and inclusion requirements and existing support process.

6. Run a small, decision-making pilot

Choose the question a pilot must answer before inviting anyone to use it. A useful hypothesis might be that the wallet route reduces repeated data entry while preserving a safe alternative. Compare it with your current journey using agreed measures: completion, time, errors, manual-review effort and customer understanding. A small test demonstrates behaviour in its sample, not universal reliability.

Use synthetic or approved test data where possible. Have a clear reason and appropriate arrangements before using real participants' information. Keep an issue register with an owner and next action for each failure. Separate a customer declining the request from a technical failure; the two need different product decisions.

Ask to see the unsuccessful cases in a structured demonstration. Record the wallet version, environment, credential and verifier configuration. Otherwise an impressive result may be impossible to reproduce when your team tries it a month later.

A practical first month

1. Week one: choose one transaction, name its owner and measure the existing journey.
2. Week two: map attributes, trust decisions, data flows and the alternative route.
3. Week three: compare implementation options and request a reproducible test demonstration.
4. Week four: review the gaps and decide whether to pilot, change scope or wait for a named dependency.

This is an illustrative work plan, not a promise that integration takes four weeks. The valuable output is a decision based on evidence. Waiting for an unavailable credential can be the correct result, provided the dependency is explicit and the work already completed remains useful.

Prepare before Irish production onboarding opens

Choose one service decision and name the legal entity making it. Record the minimum attribute needed, the issuer and credential type you would accept, the reason for processing it, recipients and the retention decision. An age threshold answers a different question from full identity, while identity alone does not establish authority to act for a company.

Prepare a draft registration record containing your organisation's identity, contact details, intended uses and requested attributes. Mark it as preparation, not an Irish application form. Keep a versioned evidence pack covering the protocol and tested role, software build, conformance results, interoperability results, security findings, accessible fallback and recovery tests.

Set a production gate requiring the applicable Irish registration route, production trust configuration, available credential types, relevant certification evidence and operational responsibilities to be verified. Ireland's official interoperability guidance is the current starting point, not a production approval.

How are other EU countries building identity?

Compare the public bodies, banks and private providers behind national identity services, then separate those existing layers from EUDI wallet commitments. The EU country tracker covers all 27 member states with dated source trails and explicit gaps. It is a readiness comparison, not a compliance ranking.

What should be ready before production?

Keep a release checklist covering supported wallets and credentials, applicable registration requirements, security review, privacy arrangements, customer support, monitoring, incident handling and rollback. Assign an accountable owner to each item. Do not convert an unresolved requirement into “supplier to confirm” and treat the programme as finished.

Finland's October 2026 implementation illustrates why these checks are separate: legal roles, certification readiness, an operational register and public launch need not arrive together. Finland expects wallets in 2027 even though its enabling legislation is in force. That is a useful readiness comparison, not evidence that Ireland has adopted Finland's authorities or process.

Use the readiness scorecard to organise the discussion and the procurement checklist when requesting evidence. MyID provides independent editorial guidance; it does not certify suppliers or approve your implementation.

In this topic: EUDI Wallet readiness

What should an Irish relying party prepare now?

Start with the topic guide

View all 12 pages in this topic

• EU country tracker
• Country evidence methodology
• Wallet gateways and verifiers
• Irish wallet demo checklist
• Readiness for Irish organisations
• Issuer, wallet and relying-party roles
• Relying-party registration
• PID, EAA and QEAA credentials
• Protocols and formats
• Credential verification flow
• Conformance and certification
• Verifier UX and fallback

View all MyID topics