DOMAIN-MAP-02 · Gift Cards

MTK for Gift Cards

Gift card programmes issue stored value, govern redemption, settle with merchants, and handle voids and fraud. MTK maps naturally onto this model: the wallet is a container, the redeemable balance is the entitlement, and redemption is the domain translation of the consume primitive.

Whether it's a closed-loop retail gift card, an open-loop prepaid instrument, or a digital voucher, the underlying structure is the same: a funded entitlement held by a recipient, governed by expiry and merchant rules, evaluated before use, and settled downstream. MTK tracks each of these steps against discrete, issuance-traceable entitlement records.

Primitive Mapping

How gift card concepts map to MTK

Each row maps a canonical MTK primitive to its gift card domain equivalent. The protocol verb is always consume (PSL-002) — redeem is a domain translation of it.

MTK Primitive	Gift Card Equivalent
Issuer	Merchant / Brand
Holder	Gift Card Owner
Beneficiary	Recipient / End User
Container	Wallet
Entitlement	Redeemable Balance / Issued Value
Constraint	Expiry Date / Merchant Rules / Usage Limits
Verification	Voucher Check / Card Validation
Authorisation	Redemption Approval / Voucher Validation Decision
Consume / Domain Action	Redeem
Mutation	Balance Reduced / Entitlement State Updated
Delegation	Send Gift / Transfer Card
Settlement	Merchant Payout
Reconciliation	Batch Redemption Settlement / Acquirer Reconciliation
Revocation / Suspension	Void / Freeze Card

Protocol Flow

How it works

The canonical flow for a gift card redemption, expressed in protocol-safe language.

01 A merchant or brand (issuer) creates a wallet (container) and issues a balance entitlement — funding the stored value at a fixed or variable amount.

02 The recipient presents the gift card for redemption. MTK checks the entitlement's lifecycle_state_canonical to confirm it is ACTIVE and not CONSUMED or REVOKED.

03 MTK evaluates constraints: expiry date, merchant eligibility rules, partial-use limits, and any usage caps. If all constraints pass, the evaluation grants an authorisation decision.

04 If authorised, the entitlement is consumed (consume primitive). The balance is reduced (mutation). For partial redemption, the remaining balance is recorded as a new or updated entitlement state.

05 Settlement records the merchant payout event. Reconciliation later aligns the redemption ledger against acquirer or programme records.

Protocol Safety

Wallet vs balance: container vs entitlement

In gift card programmes, the wallet and the balance are often conflated — but MTK treats them as distinct concepts.

Container vs Entitlement — Gift Cards

A wallet is a container. It may display the current balance, group multiple entitlements, and present programme metadata. It is not authoritative protocol truth.

The redeemable balance or issued value is the entitlement. MTK evaluates the entitlement — not the wallet — before consumption. A wallet showing a balance does not guarantee the entitlement is valid, unexpired, or unredeemed.

This distinction matters for fraud prevention: a wallet display can be spoofed or stale; an MTK entitlement evaluation cannot be bypassed without a valid authorisation decision.

Domain Considerations

Gift card-specific patterns

Patterns common to gift card programmes and how MTK represents them.

Partial Redemption

Gift cards frequently support partial use — a $50 card redeemed for $30 leaves $20 remaining. This is a permitted domain pattern, not a new protocol primitive. MTK records the consumption event and the resulting balance mutation. The remaining value is a new or updated entitlement state, not a separate entitlement unless explicitly re-issued.

Expiry Rules

Expiry dates are constraints on the entitlement. MTK's constraint evaluation engine checks whether the current timestamp falls within the entitlement's validity window. Expired entitlements receive a REVOKED or CONSUMED lifecycle state depending on programme rules. Dormancy fees and reactivation periods are constraint configurations, not protocol changes.

Merchant Settlement

After a successful redemption, settlement records the merchant payout event. In closed-loop programmes, settlement is internal. In open-loop or multi-merchant programmes, reconciliation aligns per-merchant redemption events against acquirer records. MTK's settlement and reconciliation primitives track this downstream resolution without modifying the entitlement record.

Fraud, Void, and Freeze Patterns

Fraudulent or disputed gift cards require immediate blocking. MTK supports this via the revocation and suspension overlay: a void terminates the entitlement (REVOKED lifecycle state); a freeze is a temporary suspension. Neither operation requires modifying the original issuance record — the enforcement overlay tracks the block independently, preserving audit history.

Illustrative Scope

These examples are illustrative translations, not a complete legal or operational model for gift cards. MTK's entitlement model can represent these patterns. Vertical-specific productisation — including regulatory compliance, programme licensing, and acquirer integration — is a separate implementation concern.