Skip to main content
This recipe walks through issuing a portable loyalty credential that users carry across your partner ecosystem. When a user crosses a tier threshold (e.g. Gold, Platinum), your backend issues a new credential automatically.

What you’ll build

  1. A credential schema that encodes loyalty tier, lifetime points, and membership date.
  2. A backend function that issues (or upgrades) the credential when a user crosses a tier boundary.
  3. Issuer-signed, holder-encrypted credentials stored in DStorage.

Prerequisites

  • Direct Issuance enabled for your partner account
  • A published issuance program with a loyalty schema
  • Partner JWT signing configured
  • Issuer signing keys available to your backend

Step 1: Design the credential schema

Create a schema in the Developer Dashboard (Issuer > Schemas) with fields like: See Schema Creation for full setup instructions.

Step 2: Issue on tier upgrade

When your loyalty engine determines a user has crossed a tier boundary, resolve the recipient, then build, sign, encrypt, and store a fresh tier credential. Dedupe by recipient email + program ID and revoke the previous tier credential before reissuing.
The recipient’s email (passed to initialize-user) is the routing key that determines which AIR Account the credential lands in. Resolve it from the triggering event, and never reuse a partner, service, admin, or static email across recipients — every credential issued against that email lands in the same account.

Step 3: Trigger on purchase events

Wire the issuance into your purchase or activity pipeline:

Step 4: Let verifiers read the credential

Any partner in the ecosystem can verify the user’s tier using Credential Verification. The user presents the credential (via AIR Kit SDK), and the verifier confirms tier status without accessing underlying purchase data.

Duplicate handling

Dedupe by recipient email + program ID before issuing so an event replay can’t fan out duplicate credentials. When a user upgrades tiers, revoke the previous tier credential before storing the new one. For one-time membership issuance, skip reissuance if a credential already exists for the user + schema.

Next steps