Skip to content

Changelog

1.2.1 — 3 October 2026

Switching the module off no longer switches off expiry. Until now, with Status off, a card whose order completed got no date, so it never expired, and a card past its date redeemed again. Every update brings the module back switched off, so every update opened that window until somebody switched it on again. Now a card is dated and an expired card is refused whether the module is on or off. Status switches only what a shopper and your voucher form see: the buyer's notice, the footer link, the balance page, the order panel and the Expires on field. Removing the extension still lifts expiry, because its listeners go with it. See limits and guarantees.

Fixed.

  • A recipient's name with an ampersand or a quote in it showed as & or " in the gift card panel on the admin order screen. It now shows as typed, the way the liability report already did.
  • Installing on an OpenCart release newer than any it has been tested on now writes a line to the extension's log saying so. The documentation already said it did, and it did not. It still installs.
  • Each update added the personal-data screen's permission to your user group again, so the group's permission list gained a repeat per update. It is now added only when the group does not already have it. Repeats left by earlier updates are harmless and stay where they are.
  • The note under the legal-floors table on the settings screen pointed you to a research file that is not in the package. It now points to the Legal floors page, which carries the same table.
  • The API now refuses an OpenCart API user whose key is empty. OpenCart's own form will not save one, but a row edited by hand could, and it would have matched an empty key.

Two limits now written down. The balance page shows a card's full balance even when the order that bought it is not complete, while OpenCart's checkout refuses that card. And the cap on balance-page attempts counts the address your web server sees, so behind a proxy that does not pass the visitor's address on, every holder can share one allowance. Both are on limits and guarantees.

Nothing to do on update. No new setting, table or permission, and the API answers as it did. The module still comes back switched off after the update; switch it on again to bring the shopper's screens back. Expiry no longer waits for you.

1.2.0 — 2 October 2026

A read-only JSON API, off until you switch it on. For the system that books what your store owes on unspent gift cards: one resource, card, carrying each card's face value, what is left on it, its expiry date, whether that date has passed, whether the card is switched off, and which of the liability report's figures it is counted in. The card code is never readable through it, by any name or filter, and neither are the sender, the recipient or the message. Switch it on under API on the settings screen; a caller signs in as an OpenCart API user under System → Users → API. The API lists every field, and limits and guarantees says what it cannot do.

Nothing to do on update. One new setting, the API switch, which arrives off. No new table or permission. The update registers the extension's events again, now including the API's own.

1.1.0 — 29 September 2026

The expiry date is now in OpenCart's own gift card email. The email sent when the order that sold a card completes, and the one the Send button on a card's form sends, end their redeem line with "This gift card can be used until the end of" the card's date. A card with no date, and a card already past its date, get no sentence. There is no setting that leaves it out. A theme that replaced the gift card email template, a language pack that reworded the redeem sentence, and a code two cards share all send the email as OpenCart made it; see limits and guarantees. The voucher-theme wording 1.0.0 suggested instead is no longer needed: if you added one, check it agrees with your period, or take it out.

A card you issue by hand gets a suggested date. With a validity period set, Sales → Gift Vouchers → Add fills the expiry date in from today plus that period, and says so under the box. Change it or clear it; what you leave there when you save is the card's date. Editing an existing card never fills it in, and cards sold before you set a period still have none.

The outstanding-cards list filters and exports. Under the liability figures: filter by code or recipient, by which figure a card is counted in, or by cards expiring within a number of days, and Download CSV saves the filtered list, every page of it. The figures never move with the filters. The file carries no card code and no recipient name. The CSV needs only the report's existing access permission.

Nothing to do on update. No new setting, table or permission. The update registers the extension's events again, now including the two that add the date to the email.

1.0.0 — 20 September 2026

The first release.

What it does. Gives OpenCart's own gift vouchers an expiry date, a balance page the holder can reach without an account, and one figure saying what the store still owes on cards nobody has spent.

  • A store-wide validity period, in whole months, off on a fresh install. A card's date is generated from it once, on the day that card's order first reaches a completed status, and written onto the card. Nothing reads the period again, so changing it never moves a card that already has a date.
  • Expiry enforced at every redemption path. All four places OpenCart resolves a voucher code go through one model method, and one listener governs them all.
  • The period shown to the buyer on the gift card purchase form, before they pay, wherever one is set.
  • A legal-floors warning on the settings screen, with the table of the six jurisdictions that were verified against a primary source. It warns and it refuses nothing.
  • A public balance-and-history page, challenged on the card code and the address the card was sent to. One refusal for every kind of failure, and two independent throttles.
  • A gift-card panel on the admin order screen, showing each card an order sold with its face value, what has gone and what is left.
  • An outstanding-liability report under Reports, with expired and switched-off cards counted inside the headline and hand-issued and not-yet-complete cards shown beside it.

Two limits to read before you install, both written out on limits and guarantees: the expiry date does not reach OpenCart's own delivered gift card email, and on OpenCart 4.0.x editing a completed order can silently restore a partly spent card to its full face value.

It runs on the OpenCart 4.0.2.x line only, and refuses to install above it. OpenCart removed the gift voucher feature outright in 4.1.0.0, so there is nothing there to extend. See which releases this runs on.

What an update keeps

Your settings come back, with the exceptions below. An update is an uninstall and then an install, and OpenCart deletes an extension's settings at the uninstall step. Gift Cards keeps its own copy of them and puts them back afterwards. They are one set for the whole installation rather than one per store.

These are asked for again rather than put back:

  • module_gift_cards_status — The module comes back switched off after an update, the way a fresh install does. An update is an uninstall and a reinstall, and putting the switch back on is this extension deciding on the merchant's behalf to resume changing their storefront before anybody has looked at what the new version does. Expiry carries on through that window: cards are still dated and expired cards still refused. Switch it back on with the Status switch on this extension's settings screen to bring the shopper's screens back.
  • module_gift_cards_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.
  • module_gift_cards_lookup — The lookup comes back on after an update, because on is where it ships. A merchant who switched it off and wants it to stay off across an update has switched off the module as a whole, which is remembered no more than this is — an update is an uninstall and a reinstall, and every setting in this extension is put back at the value it shipped with.
  • report_gift_cards_status — The report comes back offered after an update, because offered is how it ships — the same answer every other setting in this extension gives, which is that an update puts each one back at the value it shipped with. It is also the answer that keeps the report discoverable: OpenCart deletes this setting group when the report alone is removed from Extensions > Reports and puts nothing back, so a merchant who removed and re-added it from that list is asking for the report right now and gets it.
  • report_gift_cards_sort_order — The position comes back at 0 after an update, with the switch above it. The two are written and deleted together by OpenCart, so remembering one and not the other would be a report that came back at a position nobody chose while claiming to remember where it was.

A setting a release adds does not change what your store does. Its default is what Gift Cards did before the setting existed, so an update never asks you to go and set something to get back the behaviour you already had.

What this cannot tell you is whether a release changed how a setting behaves, as against whether it survives. Nothing derives that from the code, so it is written by hand: a release that changes an answer you relied on says so in its own entry above, as its own paragraph and never among what is new.