Gift cards and store credit are both native features of Adobe Commerce, and neither exists in Magento Open Source, where each needs a separate extension. Store credit is an account balance a shopper spends at checkout and a merchant uses for refunds. Gift cards are redeemable codes applied like a coupon. On Hyva, the redemption screens are interactive, so they need a Hyva-ready version whether you run the native feature or an extension.
For a brand that leans on gift cards over the holidays or uses store credit to keep refund money in the business, these are revenue and retention tools, not afterthoughts. Getting them to render on a Hyva development build, without a broken gift card form on your highest-traffic weeks, takes the same planning any interactive Magento feature needs on Alpine.js. This guide covers how both work, why refund-to-credit matters, and what it takes on Hyva.
Native to Adobe Commerce, extensions on Open Source
This is the first fork in the road. Both gift cards and store credit ship in Adobe Commerce and are absent from Magento Open Source. If you are on Open Source, you add each through a third-party extension, which changes both the cost and the Hyva compatibility picture.
| Feature | Adobe Commerce | Magento Open Source |
|---|---|---|
| Gift cards | Native (virtual, physical, combined) | Extension required |
| Store credit | Native, including refund-to-credit | Extension required |
| Gift card to store credit | Supported natively | Depends on the extension |
| Hyva rendering | Native frontend needs a Hyva-ready path | Extension must ship Hyva support |
The practical consequence is that an Open Source merchant choosing an extension should confirm Hyva support before buying, while an Adobe Commerce merchant needs a plan to render the native gift card and store credit frontends on Hyva. Both roads end at the same requirement: the interactive screens have to work on Alpine and Tailwind.
How gift cards actually work
A gift card in Adobe Commerce is a product type with three flavors: virtual (emailed to the recipient), physical (shipped), and combined. The buyer sets an amount or picks from preset amounts, optionally adds a recipient name, email, and message, and buys it like any other product.
Redemption works like a coupon. The recipient enters the gift card code in the cart or at checkout, and the balance applies to the order. A shopper can apply one card or several, and a card can cover all or part of an order. Gift card holders with an account can check the remaining balance from their account dashboard, and in Adobe Commerce a card balance can be credited to the customer’s store credit instead of being spent code-by-code.
Two things merchants often miss. First, a sold gift card is a liability, not revenue, until it is redeemed, which matters for how finance books it. Second, gift card expiration and escheatment (unclaimed-property) rules vary by jurisdiction, so the expiration settings are a compliance decision, not just a merchandising one. Confirm the rules for the markets you sell to rather than guessing.
How store credit works, and why refund-to-credit matters
Store credit is a balance attached to a customer account. Customers spend it at checkout like a payment method, and administrators can add to it manually or, more importantly, issue refunds as store credit instead of returning cash.
That refund-to-credit flow is the quiet margin protector. When a customer returns an item and you refund to store credit, the money stays in the business and usually comes back as another order, often a larger one. It also speeds up the refund for the customer, who gets an instant balance rather than waiting on a card reversal. Used well, store credit turns returns from a pure loss into a retention moment. Adobe’s own store credit documentation covers the admin and account mechanics.
The trade-off is customer experience and, in some places, law. Some jurisdictions require a cash refund option, so refund-to-credit is often a default you offer rather than the only choice. Design it as the easy, attractive option, not the forced one.
What it takes to render both on Hyva
Gift cards and store credit each touch several interactive storefront surfaces, and every one of them is a place the default or extension frontend can fail on Hyva.
- The gift card product page. The amount selector, preset buttons, and recipient fields (name, email, message) are interactive. Built for Luma, they rely on Knockout or jQuery that Hyva does not load, so the form needs a Hyva-native version or the customer cannot buy a gift card at all.
- Applying a code at checkout. Entering a gift card code, or spending store credit, happens in the cart and checkout. Hyva favors a native checkout, so the apply-code and use-credit steps must render there. Many extensions now ship dedicated Hyva Checkout packages for exactly this.
- The account balance and history screens. Customers check gift card and store credit balances in their account. If these break, you get support tickets instead of self-service.
Extension vendors have adapted. Store credit and refund extensions offer Hyva theme and Hyva Checkout packages, and several gift card extensions state compatibility with recent Hyva versions. Mirasvit’s store credit and refund extension, for example, is built to render on Hyva. The rule is the same as ever: confirm Hyva and Hyva Checkout support for your exact version before you commit, because “Hyva compatible” sometimes means the theme but not the checkout.
Keeping gift card and credit pages fast
Because gift card pages spike in traffic during holidays and promotions, they are exactly the pages you cannot afford to be slow.
- Render the gift card form in Alpine, not a grafted Knockout island, so your highest-traffic gift pages do not reload the legacy JavaScript stack.
- Keep balances as private content, out of full page cache, the pattern Hyva prefers over ESI hole-punching, so a customer’s store credit balance is never cached to another user.
- Do not let the amount selector block Largest Contentful Paint. The product image and price should paint first; the recipient fields can hydrate a moment later.
- Validate gift card codes server-side over GraphQL without a full page reload, so applying a code at checkout feels instant.
Done this way, a Hyva gift card page is faster than the Luma version, which is the entire point of migrating.
Balances across multiple stores
If you run more than one storefront from a single Magento installation, gift card and store credit balances raise a scope question that a single store never faces. Store credit is a customer account balance, and customer accounts are scoped to a website, so a customer with an account on one website does not automatically carry their balance to a separate website. Gift cards behave the same way: whether a card issued on one storefront can be redeemed on another depends on how your websites and customer accounts are structured.
For a multi-brand or multi-region setup, decide this deliberately. Sometimes you want a shared balance across sibling storefronts, which usually means keeping them as store views under one website. Sometimes each brand should have its own ring-fenced balances, which points to separate websites. This is the same scope decision that shapes any multi-store build, applied to money customers have already handed you, so it deserves the same care as the rest of the architecture.
Where gift cards and credit fit your platform
Gift cards and store credit are one more reason merchants weigh Adobe Commerce against alternatives. Because both are native to Adobe Commerce, a brand that relies on them heavily gets the deepest built-in support here, backed by Magento development and the wider Bemeir technology partners ecosystem for the payment and tax pieces around them. The about Bemeir page introduces the team that ships these builds as the first US Hyva Gold Partner.
Other platforms handle this differently. Shopify has native gift cards and store credit with its own limits, while Shopware and BigCommerce each have their own approaches, native or via apps. If gift cards and store credit are central to your model, that belongs in the platform decision, not bolted on afterward. For the checkout side of applying codes and credit, our Magento checkout optimization playbook covers keeping that flow fast, and the payment gateways on Hyva guide covers the payment methods that sit alongside store credit. Working with Bemeir means these features get built to render fast and reconcile cleanly, not just installed.
FAQ
Are gift cards and store credit free in Magento?
They are native and included in Adobe Commerce. In Magento Open Source, neither exists, so each requires a separate third-party extension. That means an Open Source merchant pays for and maintains extensions, and must confirm those extensions support Hyva, while an Adobe Commerce merchant gets both features built in but still needs a Hyva-ready way to render them.
How do customers redeem a gift card in Magento?
Like a coupon. The recipient enters the gift card code in the cart or at checkout, and the balance applies to the order. Shoppers can apply one card or several, and a card can cover all or part of an order. Account holders see the remaining balance in their dashboard, and in Adobe Commerce a card balance can be moved to store credit.
What is the benefit of refunding to store credit?
Refund-to-credit keeps the money in the business and usually returns as another, often larger, order, so it protects margin on returns. It also refunds the customer instantly rather than waiting on a card reversal. Offer it as the attractive default, but check whether your jurisdiction requires a cash refund option before making it the only choice.
Do gift cards and store credit work on a Hyva theme?
Only with a Hyva-ready frontend. The gift card product form, the apply-code and use-credit steps at checkout, and the account balance screens are interactive and were built for Luma. You need the native feature rendered for Hyva, or an extension that ships Hyva theme and Hyva Checkout packages. Confirm both the theme and the checkout are supported before buying.
Is a sold gift card counted as revenue?
No. A sold gift card is a liability until it is redeemed, and only becomes revenue at redemption. This matters for how finance books gift card sales and tracks outstanding balances. Gift card expiration and unclaimed-property rules also vary by jurisdiction, so treat the expiration settings as a compliance decision for your markets.
Which gift card or store credit extension should I use on Open Source?
Choose one that explicitly supports your Hyva theme version and Hyva Checkout, since that is where most break. Mirasvit, Amasty, Mageplaza, MageWorx, and Aheadworks all offer relevant extensions with varying Hyva support. Map the features you actually need (refund-to-credit, physical cards, multi-card checkout) and verify Hyva compatibility for each before deciding.
Gift cards and store credit look simple until you migrate to Hyva and the gift card form goes blank in December. They are native strengths on Adobe Commerce and useful retention tools everywhere, but only if they render fast and reconcile cleanly. Building them to work on Hyva, not just installing them, is the work Bemeir does.
