Smart Card Loyalty Programs

Smart Card Loyalty Programs

Stored-value and loyalty smart cards replaced paper stamps and magnetic stripe cards in transit, retail, and hospitality. Contactless smart cards carrying loyalty applets offer offline transaction capability, tamper-resistant point balances, and multi-application co-existence — all on a single card the customer already carries.

Stored-Value Card Architecture

A stored-value loyalty card combines two logical components:

1. Purse applet: Manages a numeric balance protected by a MAC. Debit and credit operations require reader authentication before modifying the balance.
2. Transaction log: A circular buffer of recent transactions stored in EEPROM or Flash, readable by the loyalty back-end for reconciliation.

Card EEPROM Layout (typical loyalty card):
┌─────────────────────────────────────────────┐
│  MF (Master File)                           │
│  ├── DF.Loyalty                             │
│  │   ├── EF.Balance     (4 bytes, AES-MAC) │
│  │   ├── EF.TxnLog      (20 × 16 bytes)   │
│  │   └── EF.Cardholder  (name, tier, expiry)│
│  └── DF.Payment (optional co-branded EMV)   │
└─────────────────────────────────────────────┘

MIFARE DESFire Loyalty Applet

DESFire EV2/EV3 is the most common platform for contactless loyalty deployments. A typical CreditValue APDUAPDUProtocolCommunication unit between card and reader.Click to view → sequence:

// Authenticate with store key (diversified per card UID)
APDU: 90 AA 00 00 01 02 00  (AuthenticateISO, keyNo=2)
Card: 91 AF <RndB_encrypted>

// Complete mutual authentication
APDU: 90 AF 00 00 20 <RndA_xor_RndB_encrypted> 00
Card: 91 00 <RndA_prime_encrypted>  -- 91 00 = OK

// Credit 100 points (0x0064) with CommMode.Encrypted
APDU: 90 0C 00 00 09 01 64 00 00 00 <CRC> 00
Card: 91 00

// Commit transaction to EEPROM
APDU: 90 C7 00 00 00
Card: 91 00

The CommitTransaction (0xC7) command atomically persists the balance update — if power fails before commit, the card rolls back to the pre-transaction state.

Multi-Application Cards

Loyalty applets frequently co-exist with payment (EMV) and transit applications on a GlobalPlatform-managed card. The AID registry governs which application handles a SELECT command:

The RID (Registered Application Provider Identifier) and PIX (Proprietary Application Identifier Extension) together form the full AID. Register your loyalty AID through ISO/IEC JTC1 SC17 to prevent collisions.

Offline vs. Online Transaction Models

Transit systems like London Oyster and Hong Kong Octopus use the hybrid model: small top-ups and journeys under a fare ceiling proceed offline; negative balances are reconciled online at the next top-up.

Security Best Practices

• Key diversificationKey diversificationSecurityDeriving unique per-card keys from a master key.Click to view →: Derive per-card keys as CMAC(masterKey, UID). A compromised reader's session key does not expose any other card.
• Replay prevention: Include a transaction counter in the APDU MAC; reject any command with a counter value already seen.
• Balance ceilings: Enforce a maximum stored value (e.g. equivalent of $50) to limit exposure from lost or cloned cards.
• Audit log signing: MAC every transaction log entry so tampering is detectable at reconciliation time.
• Card blacklisting: Maintain a hot-list of revoked card UIDs at readers that sync on connectivity; even offline readers can block known-bad cards.

Use the Card Identifier to identify the card platform and the APDU Builder to inspect or replay loyalty APDU sequences during integration testing.