Settings

Gift Cards keeps its settings in OpenCart's own setting table, under the module_gift_cards group. You set them at Admin > Extensions > Extensions > Modules > Gift Cards.

Each key below carries where it applies. per store means a multi-store install can hold a different answer per storefront, and both are honoured: a read takes what that store holds, then what the default store holds, then the shipped default. install-wide means one thing serves every storefront, and the key's own description names that one thing.

Scope

Key	Default	What it does
module_gift_cards_status install-wide	0	Whether Gift Cards is switched on. Off on a fresh install, so that installing it changes nothing about the storefront until you have looked at the rest of this screen. Set by the Status switch on this extension's own settings screen. It switches what a shopper and the voucher form see: the buyer's notice, the footer link, the balance page, the order panel and the Expires on field. It does not switch off expiry: a card is dated when its order completes, and an expired card is refused at checkout, whether it is on or off.
module_gift_cards_api_enabled install-wide	0	Whether the extension answers API requests at all. Off, every API route answers 404 api_disabled in the API's own JSON envelope, so an extension with its API off is shaped like one that has none. Read once for the whole installation from the default store rather than per store, because the one thing it serves is OpenCart's own API user, which has no store of its own — and a gift card has none either. It is a separate switch from the extension's own Status, and the two are read independently: the API answers whether or not Status is on, because what the store owes on its gift cards is the merchant's own record and a storefront switch should not hide it. No card code is ever readable through it.

Expiry

Key	Default	What it does
module_gift_cards_validity_months install-wide	0	How long a gift card is valid for, in whole months, counted from the day its order first reaches a complete status. 0 — which is what a fresh install has — means cards get no expiry date at all and nothing about your storefront changes. Set it to 12 and a card whose order completes on 15 November 2026 is dated 15 February 2027 for 3, 15 November 2027 for 12, and so on; a period landing on a day the target month does not have is pulled back to that month's last day rather than pushed into the next one, so one month after 31 January is 28 or 29 February. The period is read once, at that moment, and what is stored on the card is the date it produced — so changing this number later moves no card that already has one. Cards you issue by hand in Sales > Gift Vouchers have no purchasing order, so there it is only a suggestion: the Add form fills the date in from this period, you can change or clear it, and what you leave in the box when you save is the date the card gets. It is never applied to a hand-issued card behind your back, and an edit never fills it in.

Balance lookup

Key	Default	What it does
module_gift_cards_lookup install-wide	1	Whether the storefront page where somebody checks a gift card balance answers. It is a public page — the person holding a gift card is usually not the person who bought it and usually has no account here, so it asks for the card code and the address the card was sent to rather than a login. Switch it off and the page returns Not Found; expiry is still enforced at redemption and the outstanding-liability figure is still reported, because neither of those goes through it.

Reports

Key	Default	What it does
report_gift_cards_status install-wide	1	Whether Outstanding gift card liability is offered under Reports > Reports. Installing the module registers that report, writes this setting and grants your user group permission for it, so the entry is simply there — OpenCart gates it on this setting and on that permission, and a store with one but not the other has the report installed and invisible. Kept under the report_gift_cards code rather than this module's own, because OpenCart deletes a report's settings when the report alone is removed and the module's must not go with them. Read once for the whole installation rather than per store: what it serves is the admin's own Reports list, which no storefront has a copy of.
report_gift_cards_sort_order install-wide	0	Where that report sits in the Reports list, among every other report the store has. Under the report_gift_cards code for the same reason, and installation-wide for the same reason.

Advanced

Key	Default	What it does
module_gift_cards_diary_verbose_until install-wide	0	When detailed logging stops, as a unix timestamp, and 0 is off. Turning Detailed logging on from this extension's settings form stores the moment two days from now; the writer compares that against the clock every time it is asked for a DEBUG line, so the window closes on its own with no scheduled task and nothing to clean up. While it is open this extension records what it did in far more detail, and the shared diary consequently holds less history.

What you cannot change, and why

These are fixed on purpose. Each one is a decision with a reason beside it rather than a setting nobody got round to adding.

Scope

Gift Cards never writes to OpenCart's own voucher tables — not a column added to them, not a row, and not status on a voucher. Core stays the ledger and this extension is a layer over it, which is what makes uninstalling safe: take Gift Cards off and every card the store has sold is exactly where it was and still redeems. An extension that edited core's rows could not make that promise, and an OpenCart upgrade would fight it for the column.

Balance lookup

The balance page challenges on the card code and the address the card was sent to, and there is no setting that lets the buyer's address in instead. A gift card is normally bought by one person for another, and an address the buyer chose is one the buyer can use to watch the recipient spend their present. There is also no setting that puts the page behind a login, because a recipient with no account is the person the page is for.

Every way the balance page can refuse gives the same sentence — a code it does not recognise, an address that does not match, a card you switched off, and too many tries from one place. There is no setting that makes it more specific. A refusal that said which half was wrong would let somebody with no card at all work out which codes exist, one guess at a time.

How many balance checks are allowed before the page starts refusing is fixed, and counted two ways at once: per address the requests come from, and per card. Neither is a number you can raise. A merchant raising the first to help one customer would be raising it for everybody, and the second is what stops one card being worked on from a hundred addresses. This is a departure from the specification, which listed these thresholds as settings, and it is recorded here rather than left as a difference somebody has to notice: a threshold on a public page over a bearer credential is a security control, and a security control a merchant can widen from a form is one an attacker can widen from a form the day they reach an admin session. The numbers are published below instead, so what is fixed is at least not also hidden.

Rule	Value
Attempts from one address, per window	10
Attempts against one card, per window	5
The window, in minutes	15

Reports

The outstanding-liability figure is installation-wide and as at this moment, and there is no date filter and no per-store split. What a store owes on its unspent gift cards is one number; a date box would make it an argument about which number, and a merchant comparing two of them would be comparing two answers to different questions. Every amount is summed in the store's base currency, which is the currency OpenCart stores a card's face value in, so a multi-currency store gets one honest total rather than a mixture.

What the headline counts is fixed and cannot be reconfigured: cards whose purchasing order reached one of the order statuses you nominated as complete, and which still have something left on them. Expired cards and cards you switched off are counted inside that figure and broken out beside it, because neither forfeits what is owed. Cards you issued by hand and cards whose order has not completed are shown beside it and never added into it, because no money was taken for either. A setting that let the headline include any of those would be a setting that changes what the number means without changing what it is called, which is worse than no number.

Refunds

Refunding an order that sold gift cards never voids a card, takes back what has already been spent off one, or changes a balance — and there is no setting that turns any of that on. What you get instead is a panel on the order screen showing each card the order sold, its face value, what has gone and what is left. OpenCart already does the part that is not a judgement call: a card stops being redeemable on its own once the order that sold it leaves a complete status. The rest is a live money question — somebody who was given the card has already spent part of it, and whether you or they absorb that is a decision about two people we cannot take for you.

Scope

Uninstalling Gift Cards does not remove any of its tables, and there is no button that does. In OpenCart an update is an uninstall followed by an install, so a tidy-up on the way out would erase every expiry date you have ever set, every time you updated — and, with the settings mirror gone with them, would put the store back to issuing cards that never expire. OpenCart deletes the settings themselves and this extension writes them back out of that mirror; the dates stay where they are, because nothing would put those back.

Expiry

The store-wide validity period never reaches a card that already has an answer, and there is no button that makes it. It is a generator and not a fallback: it is read once, at the moment a card's order first reaches a complete status, and what it writes is a literal date onto that card. Nothing reads the period again — not the apply-code box, not the balance page, not the liability report — so shortening it next year cannot take a day off a card somebody paid for this year, and lengthening it cannot give one away either. That is a property of where the number is stored rather than a rule somebody has to remember, which is the only kind that holds. It also means a card issued before you installed Gift Cards, or before you set a period, keeps having no expiry date: there was no moment at which the period could have been read for it, and inventing one later would be the retroactive change this refusal is about.

A card's expiry date is added to OpenCart's own gift card email — the one sent when the order that sold it completes, and the one the Send button on Sales → Gift Vouchers sends — and there is no setting that leaves it out. A date has to travel with the card: the recipient is usually not the buyer, never saw the checkout, and a date they cannot see is exactly the surprise an expiry date should not be. A card with no date, and a card already past its date, get no sentence. The date is silently absent in three cases, all of which send the email exactly as OpenCart made it: a theme whose mail/voucher.twig does not print text_redeem, a language pack whose redeem sentence does not carry the code as a single %s, and a code that two cards share, because the email names the card only by its code.