Appmint Gift Cards: issue, redeem and manage value

▶ Play video

Watch on YouTube ↗

Video chapters

1. 0:00 Welcome
2. 0:08 Overview: how gift card value works
3. 0:38 Part 1 · Sell gift cards in your store — Selling a gift card: explained
4. 0:56 Make a product a gift card
5. 1:23 Jordan buys two cards, paid with Stripe
6. 2:24 The sold cards in the Gift Card Center
7. 2:52 Part 2 · Issue cards by hand — Issuing by hand: explained
8. 3:16 One card, a printed batch, a list from a CSV
9. 5:11 Give one printed card away
10. 5:38 Part 3 · Spend it at checkout — Spending a card: explained
11. 5:51 Card page, then a purchase paid in full
12. 6:41 Part card, part Stripe
13. 7:26 A spent card
14. 7:34 Part 4 · Track and support — Support actions: explained
15. 7:56 Refund an order onto the card
16. 8:21 Activity, suspend, adjust, transfer
17. 9:20 Change a card's expiry
18. 9:42 Reissue, cancel and refund the purchase

Written guide

Overview

Issue or sell stored value, deliver it deliberately and follow the card’s balance through redemption and later support actions.

Before you start

A gift card is stored value. Its serial identifies the record for staff; its redemption code/PIN enables spending and should not be included in public course screenshots. The local example issued $50, redeemed $30 against order GKEJ9KIXU and later credited $5, leaving $25. That internal gift-card lifecycle is separate from charging an external card to buy a gift card.

01. Configure tender and choose issuance type

Why this matters

Issuing value internally differs from selling a gift-card product. The tender integration allows checkout to redeem existing value.

Follow these steps

Configure the internal gift-card payment provider through Gateway Manager → Integration Builder → Payment and save/activate the intended configuration. Open Storefront → Gift Card. Inspect Overview, Cards, Batches and Activity. Choose Issue gift cards and One card. Enter Value, Currency and the intended card type, recipient and activation/delivery choices. For a single card set Who is it for, optional recipient message, Send on and Expires. Empty Send on means now; empty Expires means never. Choose Message template and inspect the activation checkbox before issuing. For a promotional type enter Campaign when attribution is needed. Review before issuing.

Check the result

A promotional card creates value without proving customer payment. Selling a card requires its own purchase/order evidence. Keep codes and PINs masked outside the controlled example.

Issue one card deliberately

1. Open Storefront → Gift Card → Issue cards (the drawer title is Issue gift cards) and select One card.
2. Enter Value and Currency. Review Type and optional Name; do not confuse a card name with its recipient.
3. Under Who is it for, select the intended customer or enter the required contact details. Only enter a real recipient when you intend delivery; issuance with immediate activation/contact can send.
4. Inspect Send on, Expires, Message template and Ready to spend right away. The latter activates on issue. Expand Spending rules before issuing if restrictions are required.
5. Read the final button amount, choose Issue once and retain the returned serial. If delivery reports failure, open that issued card rather than pressing Issue again.

Historical pre-issue form. No recipient has been entered; the screenshot is not evidence of sending. Blank Send on means now, not disabled delivery.

Current delivery feedback: the shared issuance component keeps the issued-card result even if sending fails or returns unconfirmed. It appends “and sent” only when delivery is confirmed and displays a warning otherwise. An issuance success plus delivery warning means one card exists; recover its delivery separately.

02. Deliver and inspect the card

Why this matters

A saved holder and a sent card have separate evidence.

Follow these steps

After issuing use Open the card. Inspect serial, value, balance, status, Holder, Bought by, Message, Sent and Expires. Set holder or Change holder where needed, then Send card or Send again with the intended recipient. Inspect actual receipt separately. When PINs appear in the issue result, use Download CSV immediately if needed; the interface states they cannot be recovered later.

Check the result

A sent timestamp is not an inbox receipt. Do not issue another card simply because delivery failed; reopen the existing card and correct its holder/delivery.

03. Redeem and reconcile

Why this matters

Redemption must connect the order to the card’s reduced balance.

Follow these steps

Open a controlled customer cart and choose the configured gift-card tender. Enter the card credentials, complete the purchase and note the order number. Reopen the card and Activity, compare the redemption reference and remaining balance, then inspect Order → Payments. Test insufficient balance and only the mixed-tender path actually offered by checkout.

Check the result

Do not claim split tender works from a balance display alone. A retry must not spend the same value twice; inspect both payment and card activity after an uncertain result.

Trace the redemption to the same order

1. In the customer checkout, complete contact and delivery details, open Gift card, enter the controlled card credentials and apply them. Inspect the proposed coverage before confirming.
2. When the card covers the full total, use the displayed Place order — paid with gift card action. A coverage quote alone has not spent the value.
3. Save the order number from Order confirmed, then find it in Storefront → Order → Order Management → Payments.

Historical completed local gift-card order GKEJ9KIXU. The confirmation shows the masked code ending, amount and Paid status; it does not represent a Stripe or PayPal charge.

4. Return to Gift Card → Cards, open the issued serial and inspect its Timeline. Match the redemption's order/reference and amount. In this rehearsal $50 − $30 left $20 before any later credit.
5. After a later $5 refund onto that same card, check a distinct +$5 timeline movement and $25 balance. Do not expect the original $30 redemption to disappear. Never copy the full redemption code into a shared handoff note.

04. Support actions and restrictions

Why this matters

Suspend, transfer, reissue and adjustment have different effects on existing value.

Follow these steps

Open the card’s action panel. Use Suspend with its reason and Reactivate only when appropriate. For Adjust enter a signed amount such as -5 or 10 and the reason recorded on the card, then inspect the resulting balance/activity. Refund onto card accepts amount and Order or RMA number. Transfer uses an active destination-card picker constrained to the same currency and excludes the source card. For Transfer choose the actual destination and amount; for Reissue inspect the replacement and old-card status. Use Refund onto card only for the intended stored-value credit and trace its reference. Inspect expiry and restrictions before redemption.

Check the result

Cancel card is offered only before redemptions in this UI; it is not the same as refunding the order that purchased the card. A positive-balance reissue must be reconciled across old and new cards.

05. Batch and CSV recipient issuance

Why this matters

A batch creates identical cards; a recipient list creates one card per person. Partial failures need row-level recovery.

Follow these steps

Open Issue gift cards → A batch and enter the intended count/value/settings. For From a list, use Upload a CSV or paste the list. Supported columns are name, email, phone, amount and message; a header can reorder them. A blank row amount uses the Value above. Review the parsed people count and total value. Decide whether Send each card to its person (email and text) should be enabled. For A batch use How many (the editor accepts 1–1000), optional name and expiry. Inspect the issued count, total value and failed row messages. Download CSV where needed, open Batches and inspect the batch’s cards and delivery status. Retry only failed rows after correcting their reported issue.

Check the result

Issuing the entire file again can create duplicate value. Keep issuance, activation, delivery and redemption as separate checkpoints.

Detailed instructions

The following retained material documents earlier local work. Its pending checks remain pending; historical successful outcomes are not claims of a fresh execution. Use the source-authored instructions above to prepare the new recording, and preserve these references for comparison.

T05: Give value with a gift card

Worked example

Prepare the card we'll actually redeem. In Storefront, open Gift cards and Issue cards. Set Value to fifty dollars, use Digital and leave Ready to spend right away enabled. Give this course card a recognizable name. We leave recipient details empty for the rehearsal. Choose Issue fifty-dollar card. The result shows its Serial and Code. Use the Code at checkout; the Serial identifies the card's record. Issuing value by hand doesn't demonstrate selling a gift card.

Included controls: Overview, Cards, Batches, Activity, single issue, value/status/holder, digital/physical/promotional, batch issue, CSV import, delivery defaults, PIN.

Limitations and checks: T05 here is an essentials prerequisite excerpt; its separate single-card lifecycle later uses the cancelled practice card and must be labelled as a different exercise. No recipient/send action was performed. Copy Code click is not recorded; teach the visible Code column, not a fabricated Copy-button interaction. Use a short readable result hold; the card was later suspended and cannot be spent.

Check the result: Issued value/status/holder balance persisted, intentional notifications and batch counts verified.

Implementation reference: issue-drawer.tsx, batches.tsx.

Next-batch matching evidence: SF46-shipment-retest-card.webm.

Additional recorded lifecycle drill — not in this purchase voice batch:

A gift card stores value; creating one is not evidence that a customer paid for it. In Gift Card Center, open Issue cards. We issue a controlled fifty-dollar digital card with no recipient, and turn off active on issue for this first example. Open its details and check Inactive and fifty dollars. Activate makes it usable. Suspend temporarily prevents use; enter a reason so the history explains the decision. Reactivate restores it. For a balance correction, Adjust lets us enter minus five and a reason. The balance becomes forty-five dollars, and the timeline records Adjustment. Finally cancel this unsold practice card and reload its details. Cancelled is retained alongside the historical forty-five-dollar balance. These actions have different purposes: correcting a balance is not a sale, suspension is reversible access control, and cancellation retires this card. A separately issued active card will fund our buyer purchase; we do not send any card to an external recipient in this exercise.

This separate cancelled-card exercise remains mapped to T05; it is not the card ending JPS3 used by GKEJ9KIXU. Its retained sources remain in FULL-SCENES supplementaryVerifiedSegments.

T06: Redeem and maintain stored value

Worked example

The balance says how much remains; the status says whether it can be spent. This card started at fifty, spent thirty on our buyer's order and received five back, leaving twenty-five. It is Active. To block further spending without erasing its history, choose Suspend, give a reason and save. Reopen the card: Suspended, still twenty-five. That's different from Adjust, which changes value. Reactivate is available when spending should resume.

Included controls: checkout redemption, partial tender/cards-only, restrictions, transactions, activate, suspend/reactivate, adjust, refund onto card, transfer, reissue, cancel/refund purchase, set holder, send, expire.

Limitations and checks: No reactivation of this final course card; it stays suspended. Transfers/reissue/holder/send/expiry and split or restricted tender still need demonstrations. Avoid repeating the complete redemption/refund explanation already taught in E18/A17.

Check the result: Same card50→20redemption→25refund, Active25 before suspension then Suspended25 after save/reload; no lost value or invented reactivation.

Implementation reference: card-drawer.tsx, activity.tsx.

Next-batch matching evidence: SF48-partial-refund.webm.

E17b: Configure the internal gift-card tender

For our controlled buyer rehearsal, use the internal GiftCardProvider rather than inventing a card-processor account. Open Configuration, Integration Config and Integration Builder. Choose Payment, then GiftCardProvider and give it the recognizable name cedar-course-gift-card. Set Status Active and keep Priority one, then Save. Reload Configurations and check the stored provider, Active status and priority. This makes the internal gift-card method available to our checkout. It is a stored-value tender; configuring it does not prove a Stripe or PayPal bank settlement. We will issue a separate training card, apply it at checkout and reconcile its redemption to the resulting order.

Verified scope: internal tender setup only. External payment-provider credentials, callback and settlement remain pending under E17.

Next-batch matching evidence: SF27-28-gift-payment-setup.webm.

E18: Complete the buyer’s purchase

Worked example

Choose A4, quantity one, and Add to cart. Open the cart: twenty-five for the print plus five delivery makes thirty. Choose Checkout. Enter the buyer's email and Continue, then their full name, street, city, state and ZIP. Keep Use same address for billing selected and continue to payment. Open Gift card and apply the issued code. It covers thirty and leaves twenty on the card; applying the quote hasn't spent it yet. Choose Place order — paid with gift card. The receipt now shows Paid, thirty dollars and the card ending J P S 3. Keep the order number to find this purchase in Studio Manager.

Included controls: buyer payment, success/order handoff, order number, cart clearing, product SKU/options, contact/address, total, payment reference, paid balance.

Limitations and checks: The reserve email/name/address are course fixtures, not signup requirements. External processor settlement/mixed or insufficient tender are separate gaps.

Check the result: Same buyer/catalogue order/transaction/total on both sides and actual state; record stock settlement.

Recovery / evidence caution: If payment exists but order does not, retain reference and inspect order/transaction before retry; capture smallest actual recovery without second charge.

Implementation reference: CheckoutSuccess.tsx, storefront.checkout.service.ts.

Next-batch matching evidence: SF47-buyer-gift-purchase.webm.

A17: Refund money independently of stock

Worked example

A refund changes money; it doesn't put the print back into stock. We'll give this buyer a five-dollar delivery concession. Open the same order, check Payments, then Actions. Enter five in refund Amount, explain the concession in Reason and choose Process Refund. Reopen Payments after the confirmation. Thirty was collected, five refunded and twenty-five retained; the original gift-card payment remains below. Now open that card in Gift Card Center. Its balance rises from twenty to twenty-five, and the timeline links the refund to our order. The order and original tender agree on where the money went.

Included controls: Refunds, full/partial refund, provider rejection, stock-only return, money-only refund, both, refund reconciliation.

Limitations and checks: Full refund, stock return and provider rejection are separate unfinished branches. The reason is a delivery concession, not proof of refund allocation to financial lines or a carrier refund. Home revenue0 is current UX09, not corrected analytics; do not narrate dashboard success here.

Check the result: GKEJ9KIXU order Payments30gross/5refunded/25net, originalGCT-TM5H-Y4SW-Q677 preserved, +5card refundGCT-PWBV-3D8C-LMW4 linked same order.

Implementation reference: refund-list.tsx, storefront.payment.service.ts.

Next-batch matching evidence: SF48-partial-refund.webm.

Limitations and checks

Current UI entry and editor: . Corresponding SDK storefront schemas and the retained AppEngine references define fields and consumer boundaries. Provider calls, external delivery, payments and financial mutations were not performed for this writing task.

Next steps

You can now follow the module from its configuration to the record that proves the result. Use the relevant chapter to revisit an alternative or troubleshoot the exact failed handoff.