Gifting
Gifting lets a customer buy a package for another player. The buyer pays and keeps the receipt; the recipient receives the items in game.
Not the same as Gift Cards. A gift card is store credit that pays for an order the recipient chooses themselves. Gifting delivers a specific package you chose to someone else. A customer can use both at once: pay for a gift with a gift card.
Turning it on
Gifting is off by default. Enable it under Store settings > Checkout > Allow gifting.
Until you do, no gift option appears on your storefront, and any gift order submitted against your store through the API is rejected.
Two things are worth understanding before you enable it, because both surprise store owners:
- Discord role rewards are skipped on gift orders. FluxStore only holds the buyer’s linked Discord account, never the recipient’s, so there is no correct account to grant a role to. If a package’s main value is its Discord role, gifting it delivers less than the buyer expects. They are warned before paying.
- Per-package purchase limits are consumed by the recipient. A limit exists to stop one player accumulating a package, and the accumulating player is whoever receives it.
What the customer sees
On your storefront, the customer presses Buying for someone else? on the username prompt, then enters their own username and the recipient’s.
From that point the whole catalogue is priced for the recipient: tier upgrade pricing, purchase limits and owned-tier state all reflect them, not the buyer. A banner across the top of the page reads “You are shopping for Bob”, and the checkout page carries a second gift indicator immediately above the pay button that cannot be scrolled past. The sidebar and header show Shopping for with the recipient’s name and skin, so the buyer is never left guessing whose store they are looking at.
Choosing Stop gifting clears the cart and signs them out, returning them to a clean session. This is deliberate: everything in the cart was priced for the recipient, so those prices are meaningless once gifting ends.
Who gets what
Gifting splits an order between two people. The rule is that goods follow the recipient and money follows the buyer.
| Follows the recipient | Follows the buyer |
|---|---|
| The items, ranks and perks themselves | Payment and the receipt |
| Tier upgrade pricing | Loyalty points earned and spent |
| Per-package purchase limits | Coupons and gift cards applied |
Delivery commands ({player}, {uuid}) | Order confirmation email |
| Which entitlement a refund revokes | Purchase history |
Loyalty is the one that catches people out. Points are bought with money, so the buyer earns and spends their own. The recipient never gains or loses loyalty from a gift they did not pay for.
What cannot be gifted
- Subscriptions. A recurring payment where the payer and the beneficiary differ raises questions about who can cancel and who is billed on renewal, so it is not supported. The gift option is unavailable while a subscription is in the cart, and checkout refuses it.
- A package the recipient already owns, or a lower tier in a chain where they already hold a higher one. Gifting Rank 1 to a player who holds Rank 3 is refused rather than charged. This rule applies to ordinary purchases too, not only gifts, and is covered under Tiered upgrades.
- A package whose purchase limit the recipient has reached.
Refunds and chargebacks
A refund or chargeback on a gifted order revokes the recipient’s entitlement, exactly as it would for a normal purchase. If you refund a gift, the recipient loses the perk, not the buyer.
This is deliberate. If gifts survived chargebacks, gifting would become a way to obtain goods for free: buy a gift to a second account, then charge back. The cost is that a recipient who did nothing wrong can lose a perk because of the buyer’s payment, so it is worth a clear answer ready in support.
Delivery commands
On a gift order, {player}, {username} and {uuid} resolve to the recipient, so a command like
give {player} diamond 64 delivers to the right person with no change needed.
{email} and {discord} still resolve to the buyer, since those are the contact details
FluxStore actually holds. A welcome command using either addresses the person who paid.
Four placeholders exist for naming the two parties:
| Variable | Resolves to |
|---|---|
{buyer_name} | Whoever paid, on every order. On a gift that is the gifter |
{buyer_uuid} | The same person’s UUID |
{gifter} | The buyer’s username on a gift order, empty otherwise |
{is_gift} | true on a gift order, empty otherwise |
{gifter} is empty on a normal order, which is right for a “gifted to you by” message but wrong for a
command that must act on the payer either way. A refund or chargeback command using ban {gifter}
would send ban with a missing argument on every non-gift order. Use {buyer_name} or
{buyer_uuid} there, which resolve on both.
For example:
tellraw {player} ["",{"text":"This was gifted to you by ","color":"gray"},{"text":"{gifter}","color":"gold"}]Usernames that cannot be verified
On a store using offline-identity mode, a recipient’s username is not checked against Mojang. The buyer is warned to check the spelling, because goods delivered to a mistyped username cannot be recovered.
On a store using premium_required, a recipient username that does not resolve to a real Minecraft
account is refused at checkout, the same as it would be for the buyer’s own username.
If a customer changes the recipient while items are already in their cart, the prices shown on those existing items are not refreshed. FluxStore always charges the correct, recipient-accurate price, so nobody is ever overcharged or undercharged, but the number on screen can be stale until the cart is touched again. Tell customers who see a price that looks wrong after switching recipients to remove and re-add the affected items.
Through the API
Gift sessions can also be created through the checkout API by including a gift object. See
Create a checkout session.
Order webhooks carry the recipient as well. player_username stays the buyer on a gift order, so
existing integrations keep working, and recipient_username is the new field naming who received the
goods. Read recipient_username when it is present.