01Start with the relying party and the business purpose
Before selecting endpoints or SDKs, determine which legal entity is actually requesting wallet information and why. The European Digital Identity framework requires wallet-relying parties providing digital services to register and to state their intended use, including the data they plan to request.
That makes the verification policy a business and compliance boundary as well as a technical configuration object. Adminyra models those policies separately so applications can use an approved request instead of assembling arbitrary claims at runtime.
Keep the wallet protocol behind a verifier boundary
Remote wallet presentations use a verifier-side protocol flow. The official EUDI reference verifier implements OpenID4VP and exposes separate APIs for the relying-party application and wallet interaction.
Adminyra keeps that protocol layer behind a stable application API. The calling SaaS product works with concepts such as relying party, policy, verification session, status and webhook while the verifier core can evolve as the ecosystem changes.
Use sandbox and production as genuinely different environments
Sandbox integration should prove the user journey, tenant routing, policy model and callback handling without pretending that test trust material is production identity infrastructure.
Production rollout then adds the national registration, certificates, trusted issuer validation, monitoring and key-management controls required by the real ecosystem. Separating those environments early prevents test shortcuts from becoming production architecture.