#Credential Receiving

The Wallet API v2 receives credentials from an issuer using OpenID4VCI 1.0. You hand the wallet a credential offer — typically an openid-credential-offer:// URL from an issuer such as Issuer2 — and the wallet claims the credential and stores it.

#How It Works

Receiving a credential runs through five steps:

1. Resolve the offer — parse the offer and fetch the issuer's metadata.
2. Get an access token — exchange a pre-authorized code (or an authorization code) for a token.
3. Sign a proof of possession — prove the wallet controls the holder key.
4. Fetch the credential — request it from the issuer's credential endpoint.
5. Store it — the credential is saved to the wallet's credential store.

#Two Ways to Receive

• Full flow — a single call (POST /wallet/{walletId}/credentials/receive) runs all five steps for you. This is the recommended path, and what the credential guides below use.
• Isolated Flow — drive each step yourself. Use it for custom wallet UIs (resolve-offer returns issuer display and per-offer credential details for consent before accept), the authorization-code grant, deferred issuance, and advanced options like inline keys, client attestation, and storing fetched credentials with storeInWallet.

#Supported Formats

• SD-JWT VC (IETF)
• W3C VC (JWT-signed)
• ISO 18013-5 mDL

#Start Receiving

Choose the credential type that matches your use case:

• SD-JWT VC via OID4VCI
• W3C VC via OID4VCI
• mDL via OID4VCI

Need fine-grained control? See Isolated Flow.