Gift cards appear late in most ecommerce scoping documents, usually as a single line under “nice to have,” estimated by someone who has seen the plugin listing and assumed the rest.
Then, roughly two thirds of the way through the build, somebody asks the question that changes the timeline: what happens when a customer buys a card online and spends it in the shop?
Why This One Is Structurally Harder
A gift card is not a discount code. A discount code is a rule — it can be evaluated independently, in any system, as many times as you like, and two systems evaluating it separately will reach the same answer.
A gift card is money with a location. It has a balance, that balance decreases, and the decrease has to be visible everywhere at once. Two systems holding their own copy of a balance is not a caching problem; it is a reconciliation problem, and reconciliation problems in retail resolve into either lost revenue or an angry customer at a till.
Omnichannel redemption requires every channel — POS, web, app — to read and write the same balance through a shared integration layer. Without that, each channel keeps its own private view of what the card is worth. And the timing is not theoretical: a customer may buy a card online, add it to a wallet, and spend it in-store the same day.
A card has to be spendable exactly once, from either channel, with both channels agreeing on what remains. Everything difficult about gift cards is contained in that sentence.
The Four Failure Modes
They are consistent enough to check for by name.
Double spend. The card is presented online and in-store close enough together that neither system has seen the other’s deduction. Small amounts, but it is real money and it is unbounded until somebody notices.
Phantom balance. The customer is told they have 400 remaining at the till, having spent 250 online that morning. The staff member has no way to verify who is right, and resolves it in the customer’s favour because the alternative is an argument in front of a queue.
Orphaned cards. Cards issued by the old system before the migration, in a format the new one does not recognise. These surface for years — a card bought as a Christmas present in 2024 and redeemed in 2027 is entirely normal behaviour.
Silent expiry drift. Expiry rules implemented twice, slightly differently, in two systems. Legally exposed and impossible to explain to a customer holding a card that one till accepts and another does not.
Each of these is cheap to design for up front and expensive to discover in production, because by then you have real cards in real wallets and no clean way to migrate them.
What This Looked Like on Gutta på Haugen
Gutta på Haugen is a specialty food shop in Oslo, trading since 1994, with several branches. They already sold physical gift cards over the counter.
This constraint arrived as a client requirement rather than as one of our ideas — which is unusual on that project, where the recipe-to-basket and subscription work were both our proposals. The designer’s account is one sentence long:
“Client requirement, they already had physical gift cards.”
The commercial logic is not complicated. A new web store that could not honour existing cards — or that issued cards the shops could not accept — would have split the brand in two. A customer holding a Gutta gift card thinks they hold credit at Gutta, not credit at a particular sales channel. Any design that contradicts that intuition is wrong regardless of how the systems are wired.
What we designed: a single field in the cart that accepts either a discount code or a gift card, with one Claim action, plus a gift-card purchase flow offering in-store pickup or online delivery.
That one shared field is a deliberate simplification. Customers do not reliably know which of the two things they are holding — a code is a code — and forcing them to classify it correctly before it will work generates support contacts for no reason. Accept the string, work out what it is, apply it.
On what shipped. Cross-channel balance synchronisation was documented on this project as feasibility research and a technical roadmap — the integration work with the client’s inventory and till system was scoped rather than confirmed as delivered. We flag it the same way in the whitepaper, and it is deliberately not represented among the figures on the results page. The design and the constraint are documented; the integration status is not ours to claim.
That is itself the useful lesson. On a project where the storefront, the product pages, the subscriptions and the paid media all shipped, the gift-card strand is the one that resolved into a research programme.
The Questions To Ask in Week Two
If your business already sells anything physically that carries a balance — gift cards, store credit, loyalty points, deposit schemes — these belong in discovery, not in the second half of the build.
- Where does the balance actually live today? Name the system. If the answer is “the till software, we think,” that is your first task.
- Does it have an API? Read and write, or read only? Rate limits? Anything real-time, or nightly batch?
- Who is the source of truth during an outage? If the web store cannot reach the balance service at checkout, does it decline the card, or accept it and reconcile later? Both are legitimate. Only one of them can be the answer.
- How many cards are outstanding, and for how much? This is a liability on your balance sheet and a migration scope in the same number.
- What is the oldest card still in circulation? It sets the format range you have to support.
- Who resolves a disputed balance, and with what evidence? A policy written before the first dispute is worth ten written after.
Loyalty points raise every one of these questions again, in the same shape. On Gutta, points are surfaced in three places — against the product price, in the cart, and at checkout — which means three places that need to agree with a scheme owned somewhere else.
The Pattern Worth Generalising
Anything your physical business already does becomes a constraint the moment you add a channel, not a feature you get to specify freely. Gift cards, stock levels, pricing, promotions, returns — all of them existed before the website and all of them have an incumbent system with opinions.
The scoping instinct that catches this is simple: for every commercial behaviour the shop already performs, ask which system currently owns the truth. If the answer is a system you are not building, you have an integration project. Discover it in week two, not week twenty.
This is job four of eight in the counter inventory — the full set is in the counter problem. The same discovery instinct applies to what a manual order process is actually costing you, to replenishment, and above all to measuring the process you are about to delete.
