Sell Value Up Front
Capture revenue before the recipient chooses what to buy and create another purchase path for customers shopping for gifts.
Checkout using your account
This form is protected by reCAPTCHA - the Google Privacy Policy and Terms of Service apply.
Checkout as a new customer
Creating an account has many benefits:
30-day money back guarantee
Gitlab access is only given to Agencies and Freelancers after
approval process.
Please note: we do not provide installation or implementation services for our extensions.
Installation should be handled by the developer or agency managing your store. This approach ensures:
Although we don’t offer installation, we maintain a curated list of recommended development agencies experienced with our solutions.
If you'd like to receive this list, please contact us at [email protected].
Partnership Inquiries
Gift cards bring revenue forward, create new customer acquisition opportunities and give shoppers an easy way to buy for somebody else. The platform should make that experience simple without creating financial uncertainty behind the scenes.
Capture revenue before the recipient chooses what to buy and create another purchase path for customers shopping for gifts.
Every sent gift card can introduce a new recipient to the store through a purchase funded by an existing customer.
Let shoppers choose the value, recipient, message, delivery date and visual design instead of sending a generic voucher code.
Ledger-based accounting, reservations and replay protection make the financial value behind the gift card traceable and recoverable.
The storefront experience covers the complete journey from choosing the value to receiving a finished digital card.
Configure preset amounts or an allowed open-value range. Customers choose the recipient, personal message and delivery date as part of the product purchase.
Gift-card values are validated server-side, preventing manipulated browser requests from assigning arbitrary prices.
Create reusable card designs with backgrounds, gradients, icons, starter templates, personalization tokens and QR codes or barcodes.
This gives merchant teams control over seasonal, campaign and brand-specific gift cards without needing a separate image-production workflow for every variation.
Delivery emails contain a server-rendered SVG based on the card design created in Magento Admin, with recipient and gift-card data inserted into the final artwork.
Buyers can choose a future delivery date, with scheduling resolved in the Magento store's timezone.
Claim-based processing, retries and CLI resend tooling are designed to prevent duplicate sends while giving support teams a recovery path if delivery fails.
Recipients can keep the gift card in their phone wallet instead of searching for an old email when they are ready to purchase.
Wallet integrations use your own Apple Pass Type ID certificate and Google service account configuration, with signed passes and expiring HMAC-protected links.
Logged-in customers can see gift cards they purchased or received, review balances and access available wallet actions from their Magento account.
Gift-card codes remain masked in account and administrative surfaces.
The storefront feature is only half of a gift-card implementation. The harder part is protecting the balance when checkouts race, refunds are replayed or an operation crashes halfway through.
Prevent two carts from spending the same balance.
Gift-card value is reserved during order placement through a conditional balance update. If another checkout has already consumed the available value, the second attempt is rejected before payment is taken.
Do not refund money that has already been spent.
When a purchased gift card is refunded, spent and reserved value is excluded from the refundable amount. Refunds involving currently reserved cards are stopped before an external payment gateway moves funds.
Every movement has a history.
Balance changes append audit records rather than rewriting financial history. Separate sales-document ledgers provide replay protection so repeated invoice or credit-memo processing becomes a no-op instead of a second debit or refund.
Recover from interrupted workflows automatically.
Reconciliation runs every 15 minutes and can recover missed issuance, scheduled deliveries, stale reservations and missing order-ledger operations.
Treat redemption codes like credentials.
Codes are stored as peppered hashes, transmitted in POST requests, displayed masked and protected by a throttling mechanism against repeated guessing attempts.
Match the financial model to the merchant.
Configure gift-card redemption as tender/payment or as a subtotal discount per store view, allowing projects to align checkout totals with their accounting requirements.
Without protection: both orders spend the same balance.
Atomic reservation logic makes available balance a concurrency-safe resource rather than a number read independently by two checkout requests.
Without idempotency: the same money can be returned twice.
Per-document gift-card ledgers make repeated processing of an already handled sales document harmless.
Without reconciliation: balance or delivery state can be stranded.
Automated reconciliation looks for incomplete issuance, stale holds, missed deliveries and missing accounting operations.
Without validation: the merchant can return more value than still exists.
Refund calculations account for value that has already been redeemed or is currently reserved.
A gift-card balance is effectively money behind a token.
Pepper-hashed codes, masking and lookup throttling reduce exposure if somebody tries to enumerate valid card codes.
A birthday message should arrive once.
Claim-based delivery processing prevents multiple workers from independently sending the same scheduled gift card.
The same financial logic powers Luma, Hyvä and API consumers, so agencies do not need separate implementations of redemption rules for each frontend.
Balance lookup, application, removal and customer gift-card operations are available through REST and GraphQL over the same service contracts used by the storefront.
A dedicated Hyvä package provides Tailwind/Alpine product and balance experiences rather than relying on a Luma compatibility layer.
Code generation, artwork rendering, delivery links, design validation, restriction rules and lookup protection are interfaces with default implementations, giving agencies supported seams for client-specific customisation.
Gift-card products are widely available in the Magento ecosystem. The differences become more important once a project requires concurrency safety, auditability, wallet delivery, recovery tooling and predictable developer extension points.
| Capability | qoliber Gift Cards Suite | Competing modules |
|---|---|---|
| Balance architecture | Append-only ledger with document-level replay protection | Implementation varies |
| Concurrent checkout | Atomic balance reservation | Often not publicly documented |
| Refund protection | Spent and reserved value excluded before gateway refund | Varies by implementation |
| Crash recovery | Automated reconciliation every 15 minutes | Rarely documented publicly |
| Gift-card designer | Built-in admin canvas with server-rendered artwork | Varies |
| Wallet support | Apple Wallet + Google Wallet | Varies by vendor |
| Scheduled delivery | Claim-based delivery, retries and CLI resend | Common feature; reliability architecture varies |
| Headless | REST + GraphQL over shared service contracts | Support varies |
| Hyvä | Dedicated Tailwind / Alpine module | Varies by vendor |
| Published test coverage | Playwright E2E + PHPUnit + Magento integration + PHPStan 8 | Usually not published |
“Typical Magento Extension” describes common market characteristics rather than any individual vendor. Capabilities and technical implementations vary between products. Where something is described as not publicly documented, that is not a claim that no competing product provides it.
Test coverage spans storefront purchase, scheduled delivery, redemption, refunds and Magento Admin workflows. Unit and Magento integration suites accompany the end-to-end coverage, together with Magento coding standards, PSR-12 and PHPMD checks.
Magento Open Source, Adobe Commerce and Mage-OS.
PHP 8.2 – 8.4.
Luma and dedicated Hyvä Tailwind/Alpine implementation.
REST + GraphQL using the same underlying service contracts.
Yes. A gift-card product can use predefined values or an allowed open-value range. The amount is validated on the server so a modified browser request cannot set a value outside the merchant's configuration.
Yes. The buyer can select a delivery date and the email is sent according to the store timezone. The delivery process uses claim-based processing with retries and a CLI resend option.
Yes. The suite supports signed Apple and Google Wallet passes using credentials configured by the merchant, together with expiring HMAC-protected access links.
The balance is protected with atomic reservations during order placement. If one checkout has already reserved the available value, another checkout cannot independently spend the same funds.
Refund calculations account for value already spent or reserved. The suite also records sales-document activity so replaying an already processed invoice or credit memo does not apply the same balance movement again.
Yes. A dedicated Hyvä module provides Tailwind and Alpine storefront components for gift-card purchasing and balance-related experiences.
Yes. REST and GraphQL operations expose gift-card balance, application, removal and customer-card functionality using the same service layer as the Magento storefront.
Automated reconciliation runs every 15 minutes and looks for missed issuance, deliveries, stale reservations and incomplete order-ledger operations so interrupted workflows can be recovered.