A gift card is money you have already been paid for, so the parts that matter are the ones that keep the balance honest and the code out of the wrong hands.

​
Set up the product

  1. Create a gift card product.
  2. Add the denominations you want to sell. A shopper picks one of these rather than typing an amount.
  3. Configure gift card settings for the store, including how a code is revealed.

​
Delivery

A buyer can send a card to someone else. The recipient’s name, email and a send date travel with the cart line, so buying two cards for two people in one order produces two distinct lines rather than one merged line of quantity two. Scheduled delivery requires GIFT_CARD_ENCRYPTION_KEY to be set on the deployment. With it set, a purchased code is sealed until its send date. Without it, scheduled delivery is off and codes go out when the order settles.
You can see the queue, and reschedule a send that has not gone yet, through the gift card delivery endpoints. A send that failed is visible there with its attempt count rather than disappearing silently.

​
Balances stay auditable

Every movement on a card writes a ledger row, including a balance forfeited at expiry. The sum of the ledger equals the balance, and reconciliation reports a mismatch rather than quietly correcting one, because a silent correction destroys the evidence that something went wrong.

​
Things worth knowing

Once an order has settled, a card is always minted. If something is wrong with the configuration at that point the system mints anyway and raises an alert, because the shopper has already paid. Refusals belong at the cart, before the money moves.
A card’s code is treated as a bearer credential: whoever has it can spend it. It is kept out of application logs, and the recipient-facing view link is redacted from the access log for the same reason.

​
Reference

  • The Money tab covers gift cards, denominations, deliveries and settings.
  • Store credit if you want a balance that is not transferable.