Understand gift card lifecycle states
Customer App can present gift-card denominations, purchase entry, card history, send, and redeem surfaces when the current configuration and account allow them. These are separate financial, fulfillment, email, wallet, and provider stages. A visible card, status, message, or navigation result does not prove the next stage settled.
:::warning Gift credentials and recipient data are private
Never place a gift-card code, password, recipient, sender, message, amount, wallet value, or related account/order detail in documentation, screenshots, logs, or support notes. This guide does not instruct purchase, send, redeem, wallet, payment, or order actions.
:::
Gift card lifecycle stages
| Stage | What it can represent | What it does not prove |
|---|---|---|
| Denomination/product choice | A purchasable gift-card product candidate for the current configuration | Availability, final amount, recipient, payment, or card creation |
| Cart and checkout | A gift-card product in cart and a checkout/payment journey | Successful payment, order creation, or gift-card fulfillment |
| Paid order processing | Ordering can process a qualifying paid gift-card order | Exactly-once card creation, credential safety, email delivery, or wallet credit |
| Gift-card creation | A card record and credential can be created for a qualifying order | Recipient delivery, activation, redemption, or usable balance |
| Email or provider delivery | A delivery request can be queued or accepted by an email/provider system | Recipient receipt, viewing, valid credential, or activated card |
| Card list/details | Current account history can display returned card/order states | Ownership, complete history, current credential status, or financial settlement |
| Send from order details | A pending gift-card order can expose a send form | Exactly-once send, valid recipient, provider delivery, or status transition |
| Redeem | A credential check can request redemption | Single use, wallet credit, account ownership, or usable balance |
| Wallet credit and later use | A wallet event/balance can reflect redemption and later checkout can use it | Atomic redemption, current balance, payment/order completion, or reversibility |
No stage should be inferred from another stage's UI.
Denomination and form visibility
Gift-card products, denomination labels, purchase controls, recipient fields, send forms, redeem forms, wallet areas, and status sections are conditional. Their visibility can depend on project configuration, account/session, product catalog, platform, checkout, order state, provider, and current authorization.
An amount shown for a gift-card product is a candidate product price, not a guaranteed card value, charged amount, wallet credit, or usable balance. A form opening is pre-action only.
Pending, sent, activated, and unknown states
| Visible state | Safe interpretation |
|---|---|
| Loading | Product, card, order, or action state is unresolved. |
| Empty list | No authorized card record was returned for the current section; no global absence inference follows. |
| Pending | One returned card/order record has not reached a later returned state; payment, creation, and delivery can still differ. |
| Sent | A returned state indicates a send phase advanced; delivery, receipt, credential validity, and redemption remain separate. |
| Activated or redeemed | A returned state indicates redemption/activation advanced; wallet credit, remaining balance, later use, and order payment remain separate. |
| Error | Purchase, payment, creation, send, provider, redemption, wallet, or mapping can fail independently. |
| Unknown | A response was lost, work was duplicated, or account/project/session changed before reconciliation. |
A state label is not a credential, provider receipt, or proof of complete financial settlement.
Purchase, card creation, and payment settle separately
Purchase begins with a product candidate, then cart and checkout can mutate cart/payment/order state. Card creation is a later fulfillment responsibility that must be bound to an authorized paid order and execute exactly once.
| Boundary | Required contract |
|---|---|
| Product/cart | Current enabled product and immutable product/price revision |
| Checkout/payment | Authorized account/cart/business/currency/amount and one payment operation receipt |
| Order | One authoritative accepted order result, not navigation alone |
| Card creation | Unique order-product fulfillment key and idempotent credential generation |
| Failure/recovery | Exact pending/failed/partial state without duplicate charge, order, or card |
A payment/provider success or visible order is input to reconciliation, not proof that a gift card was created or delivered.
Email delivery and duplicate-send boundary
Sending a gift card can expose recipient, sender, title, and message fields and can cross email/provider, job, plugin, push, and order-status boundaries. These are private effectful stages.
A future accepted send contract must validate the authorized current card/order, derive the intended recipient, minimize content, use one idempotent delivery operation, and return a safe status receipt. Repeated taps, retries, worker replay, provider retry, or lost responses must not produce duplicate delivery or duplicate status transitions.
Provider acceptance does not prove recipient delivery or viewing. Push or lock- screen content must not contain credentials, recipient details, or sensitive message content.
Redemption, wallet credit, and use
Redemption can require a secret credential and can reveal card-related PII or message content. Those values must never be shown in this guide or in support evidence.
Redemption, card consumption, wallet event creation, wallet balance update, card status, notification, and later wallet use require one locked, transactional or recoverable result. Concurrent, duplicate, replayed, foreign- account, or stale-project redemption must not credit twice or consume without a matching wallet receipt.
A visible redeemed result or wallet balance does not prove that a later cart, payment, or order used the credit successfully.
Credential and PII minimization
Gift-card list, order, card-detail, email, push, wallet, and provider responses must be purpose-specific and minimal. Credentials must be hidden by default and must not appear in broad order or account graphs.
Public/customer-safe state can identify only a value-free lifecycle class such as pending, sent, activated, unavailable, or unknown. It must not reveal a credential, recipient, sender, message, product price, card value, wallet amount, order reference, account identity, or provider payload.
Concurrent and partial outcomes
| Outcome | Safe interpretation |
|---|---|
| Purchase returns but no card appears | Payment/order/card creation can be partial or pending. |
| Card appears but delivery state is unclear | Creation and provider delivery differ. |
| Send reports success but status remains pending | Provider/job/order-status layers can disagree. |
| Duplicate send request occurs | Exactly-once delivery and status transition are unproved. |
| Redemption succeeds but wallet is unchanged | Consumption and wallet credit may be partial. |
| Wallet changes but card state does not | Wallet/card/notification state may be on different revisions. |
| Two redemption attempts race | Lock, single-use, wallet credit, and rollback are unresolved. |
| Account/project/session changes | Reject prior card, provider, wallet, email, and push callbacks. |
| Response is lost | Keep purchase, card, delivery, redemption, wallet, and use outcomes unknown; do not repeat automatically. |
Troubleshooting safely
- Treat purchase, payment, order, card creation, email, send, redemption, wallet, and use as separate states.
- Do not resend, redeem again, repurchase, change account/project, or place another order to diagnose an unknown result.
- Do not copy or reveal credential, recipient, message, amount, wallet, order, provider, email, or push content.
- Use only value-free state classes such as “gift-card creation unresolved,” “delivery unknown,” or “wallet credit partial.”
- A missing card or history row must not reveal existence or ownership.
Accessibility and recertification
Product/denomination choices, loading/empty/error, status sections, card rows, purchase/send/redeem forms, credential visibility, destructive or duplicate consequences, provider progress, wallet state, and unknown outcomes need clear semantic names, roles, values, focus order, announcements, and safe return. Large text, keyboard, screen-reader, Back, modal, provider-return, and reduced- motion behavior must preserve the lifecycle state without exposing private data.
Repeat isolated review after changes to gift product/denomination/configuration; cart/checkout/payment/order; card creation/credential storage; email/send/jobs/ plugins/push/provider content; list/detail/status; redemption/wallet credit/use; idempotency/concurrency/replay/recovery; account/project/session teardown; accessibility; or App/components/API authority pins. This guide does not certify current financial, fulfillment, delivery, privacy, accessibility, or deployed behavior.
Related guides: Review your cart before checkout · Review payment-method boundaries · Review wallets and loyalty · Understand order details and status · Understand notification boundaries · Use the app offline and reconnect