A Swiss business evaluating swiyu should commission a narrow verification journey before adding identity checks across its product. Decide what the customer must prove, why the business needs that proof and how the result changes a specific decision. The pilot should demonstrate the complete return from wallet to application, including refusal, expiry and failure.
The timing matters. On 4 September 2026, the federal programme announced that its Public Beta would be called Sandbox, with a dedicated Sandbox Wallet separate from the production wallet infrastructure. A buyer should therefore specify the environment clearly. A successful sandbox demonstration is evidence about an integration, not proof that a production service is available or approved for every intended use.
Ask one business question before collecting attributes
Consider a fictional Swiss membership service that needs to establish whether an applicant satisfies a particular eligibility condition. The team’s initial idea is to copy identity details into its customer database. A better discovery question is whether it needs all those details or only a verified answer to the eligibility question.
Document the decision, the requested evidence and the retention purpose separately. Have the product owner and privacy reviewer approve that list. Avoid requesting additional attributes simply because a test credential contains them. More available data does not automatically create a business reason to keep it.
The resulting brief should be understandable without protocol knowledge: the customer proves an agreed fact, the application records the approved outcome, and the user can continue or choose the defined alternative route.
Understand where the reference component stops
The official Generic Verifier guide describes a self-hosted component that performs credential verification and exposes results to a business application. The application still owns its business decision, user session, presentation of the request and use of the result.
That boundary is the custom engineering opportunity. Hosting a verifier does not automatically connect the result to the correct account, explain a refusal or protect a partially completed application from confusion. Ask the development partner to draw the components and responsibilities before estimating screens.
Include ownership of configuration, keys, deployment, monitoring and software updates in the scope. Reference software reduces implementation work, but your operating team still needs a supported deployment and a repeatable recovery process.
Bind the result to the customer’s actual session
For the pilot, create a distinct verification attempt linked to the current application journey. Define when it expires and whether the user may restart. The proposed design should prevent a successful result from one attempt being accidentally attached to another account or browser session.
Test multiple tabs, a refreshed page and an abandoned attempt. A customer who opens a second verification request should not see an old success message simply because the first request eventually completed. Show which attempt is active and preserve a clear route to restart.
Keep business approval separate from technical verification. A valid credential may satisfy one eligibility condition while the application still requires another approved step. Model that distinction explicitly in the interface and the audit history.
Design both sides of the wallet journey
The official sandbox guidance encourages organisations to test their own use cases with the trust infrastructure. Turn that invitation into a customer-journey exercise with synthetic data and agreed test credentials.
Prepare a desktop journey where the customer uses a separate phone, and a mobile journey where the application and wallet share a device. Check the explanation before the handoff and the state shown when the person returns. A technical success hidden behind an unchanged loading spinner is still a failed product experience.
The customer should understand what is being requested and what happens if they decline. Provide clear text for cancellation and a useful alternative where the business supports one. Do not describe a cancelled request as proof that the person failed an eligibility rule.
Make failure cases part of the demonstration
Ask the delivery team to walk through:
- ▸A completed request for the intended test customer.
- ▸A customer who declines to share the requested information.
- ▸An expired request that is reopened later.
- ▸A credential that cannot satisfy the requested condition.
- ▸An interrupted browser session after the wallet interaction.
- ▸An unavailable dependency with a controlled retry route.
- ▸Two concurrent requests whose results arrive in a different order.
For each case, capture the application state and the information retained. Do not rely on a presenter explaining what the system was supposed to do. The screen and operating record should make the outcome clear to the next person handling the case.
Keep evidence without keeping everything
Agree what the business needs to demonstrate later: which condition was checked, when it was checked and which authorised process used the outcome. Review whether retaining additional personal attributes or complete presentations is necessary for that purpose.
The team should test deletion and support access as deliberately as it tests a successful login. Diagnostic logs often outlive a pilot and can become an accidental copy of identity information. Use synthetic material during development, control access and document the retention behaviour before any production review.
Buy a decision-ready pilot
Useful deliverables include the journey map, approved attribute list, environment inventory, failure demonstrations, operating guide and unresolved production dependencies. The final review should let the buyer decide whether to proceed, revise the use case or stop.
TuniCyberLabs can help implement the business application around a verifier through custom software development. Describe your Swiss credential use case, including the fact to verify and the existing customer journey. Our acceptance-test checklist can help turn the pilot into evidence your product team can review.