The third-party gift-card vendor and the faked-discount-code workaround both create reconciliation debt
The default path is a third-party gift-card vendor: a separate ledger, a separate API, a separate invoice, a separate reconciliation spreadsheet. Customer service issues a refund-as-credit and finance has to chase it across two systems.
The other default is worse. Store credit faked as a one-time discount code, no balance, no expiry, no audit trail. It "works" until the customer redeems half of it on one order and asks where the other half went.
This plugin makes both store credit and gift cards native payment methods on a single Vendure balance ledger. Reconciliation is real, not approximate.
Two products, one ledger, one payment surface
Five capabilities, all in the dashboard, all on a single underlying entity.
Store credit (admin-issued)
Issue store credit from the order detail view or by API. Use it for refunds, loyalty rewards, RMA compensation, or goodwill. The credit has a balance, a currency, an optional expiry, and an audit trail of every transaction against it.
Gift cards (customer-purchased)
Customers buy a gift card on the storefront, choose a value, a template, a sender name, and a recipient email address. The recipient receives a generated card image with the code. Delivery can be immediate or scheduled.
Native payment method
Both products deduct from the order total at checkout alongside cards, wallets, and purchase orders. Refunds, partial captures, and reporting work the same way as every other tender type.
Custom gift card templates
Upload template images, position the code, value, and message elements, pick fonts and colours. The plugin renders the final card image per purchase. Custom fonts are supported and added once at plugin init.
Tax-aware accounting
Non-taxable sale, pre-tax redemption. Defaults match retail accounting in most jurisdictions. Configurable via getDeductibleTotal for custom tax engines.
One entity, two flows, one deduction at checkout
Store credit and gift cards share one underlying entity. The store-credit row is admin-issued; the gift-card row is storefront-purchased. Each carries:
- A unique redemption code
- An initial value and a live balance
- A currency and an optional expiry date
- A transaction history of every deduction and adjustment
At checkout the customer enters the code. The payment handler validates it through the StoreCreditRedemptionValidator chain, deducts from the order total, and writes a transaction against the balance.
Redemption rules are extensible. Per-customer limits, channel restrictions, and per-order caps are validators you configure. Custom validators are TypeScript classes that conform to the same interface as the built-in ones.
The motions this plugin was built for
The defaults match how retail finance teams already book it
Gift card revenue is recognised at redemption, not at purchase. Standard retail accounting treatment in most jurisdictions. The plugin ships with these defaults:
- Sale order: non-taxable
- Redemption: pre-tax deduction against the redeeming order
- Unredeemed balance: a ledger liability until spent or expired
Finance teams running their own tax engine can override the deductible total via getDeductibleTotal. Chain in loyalty-point deductions, partial captures, or other tender-type interactions before credit redemption applies.
Trusted by complex B2B commerce and enterprise retail.
What teams ask before they ship store credit
Real questions from D2C marketing, B2B operations, and engineering teams.
