Gift Card Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as a balance lookup?

The biggest scope failure in stored value is that the project sounds simple when you describe it. Read a card number, return a balance, deduct an amount. That framing survives the whole discovery phase because nobody in the room is the person who has stood at a till with eight people queuing.

The real authorisation path has partial redemption, split tender across a card and another payment method, a tip added after the authorisation in restaurants, voids and returns that must reverse to the original instrument, and stores whose connectivity is genuinely unreliable. A single deduct model handles none of those without ambiguity.

Two design decisions separate a usable platform from a Christmas incident. First, authorisation must be two phase, a hold then a capture, so that a dropped connection leaves a hold that expires rather than a balance nobody can account for. Second, offline behaviour must be a written policy rather than an accident. Either the till declines stored value when it cannot reach the platform, which is honest and unpopular, or it authorises up to a floor limit and reconciles later, which is popular and costs a bounded amount of fraud. Pick deliberately, write the number down, and make the floor limit configurable per channel and per store so you can tighten it where losses appear.

Scope release one around that authorisation model, the balance ledger and a liability report. Everything else is easier once those three exist.

What goes wrong when jurisdiction and issuance data are not captured?

The data failure specific to gift cards is that the information you will need for unclaimed property reporting can only be captured at the moment of sale, and most platforms do not capture it.

Escheatment obligations depend on the state of issuance, and in some cases on the address of the purchaser, at the point the card was sold. If your ledger records only a card number, a balance and a redemption history, then when the first audit arrives you are reconstructing jurisdiction from point of sale (POS) journals, distributor files and store master data that has changed since. That reconstruction is expensive, slow and hard to defend, and it is the moment most groups discover the problem.

The same gap shows up in ordinary reconciliation. A batch of cards sold through a supermarket rack activated three days after purchase. A franchise location redeemed against a balance that central had already written off as breakage. A promotional card the marketing team issued was never coded as a liability at all. Each of those is a jurisdiction or attribution question dressed up as an accounting variance, and each takes days to unpick.

The fix is to stamp every card at creation with its issuing entity, issuing location, jurisdiction, funding source and its own dormancy clock, then never derive any of it later. Breakage recognition runs as a scheduled process against a documented policy your auditor has signed off, producing journal entries rather than a memo. A four day month end reconciliation becomes a report your controller runs.

Why do the point of sale and distributor integrations break after launch?

Stored value integrations break at the edges of the estate rather than at the centre.

Point of sale estates are rarely uniform. A group that grew by acquisition runs Toast in one brand, Oracle Micros in another and an older till in the sites nobody has refitted, and each has different offline behaviour and a different upgrade cadence. A point of sale vendor update changes how a void is transmitted, or introduces a new tender type, and stored value transactions start arriving in a shape your reconciliation did not expect. Older estates often need a middleware shim, and shims are the first thing to break when either side moves.

Distributors break differently. Third party activation files arrive in each partner's own format, sometimes in real time and sometimes as a batch that lands late. A partner changes a file layout or a settlement term, and the mismatch does not appear as an error, it appears as a liability figure that no longer ties out at quarter end.

The controls are ordinary and effective. Reconcile per partner daily rather than per period, so a mismatch is a next morning conversation. Alert on absence as well as on error, because a distributor file that stopped arriving generates nothing. Version your integrations and record which version processed which batch. And keep a per estate test lane, because a change that is safe on one till system is not evidence about the others.

What happens when draining fraud and franchise settlement are not covered?

Two gaps recur, and both of them turn into money leaving the business without an obvious cause.

Card draining is the first, and the timing is what defeats most tooling. Cards are lifted from a retail rack, the numbers and any scratch off codes recorded, the packaging restored, and the card put back. Nothing has happened yet, because the card carries no value. When a shopper buys it and it activates, the recorded number is drained within minutes. Redemption velocity rules fire far too late. The loudest early signal is balance enquiry behaviour, because attackers poll continuously to detect activation, so rate limiting enquiries per card and per source and alerting on enumeration against number ranges catches the pattern before the money moves. Score the interval between activation and first redemption, hold first use high value online redemptions for a short review, and log every decision so you learn which racks are being hit rather than only that you refunded someone.

Franchise settlement is the second. A franchisee redeems value a central entity issued, which is an inter entity settlement with real money attached. Handled in spreadsheets, disputes arrive months later with no supporting detail and cost goodwill as well as cash. Generating a settlement entry at the agreed reimbursement rate the moment the redemption posts, with a statement the franchisee can dispute line by line, removes the entire argument.

Should you build custom or configure what you already own?

If your outstanding liability is under roughly $2 million, you operate in one or two states, you have a single point of sale estate and you do not sell through third party retail racks, do not build. Givex and Paytronix are solid at that scale, the integrations already exist, and a build would be an expensive route to the same place.

Before assuming custom, check what your current stack already offers. Your processor may already expose activation and redemption detail through an interface nobody has connected to finance. Your point of sale may already support a second tender type with proper void handling, which is often the actual blocker rather than the ledger. Your distributor may be able to send a richer activation file including the selling location, which is most of what jurisdiction reporting needs.

The build case appears when two or more of these are true. Outstanding liability above roughly $10 million with no jurisdiction breakdown available on demand. Distributor reconciliation done by hand. Franchise settlement disputes as a recurring meeting. Draining losses where your only tool is a goodwill refund. Or a need to hold stored value, loyalty points, store credit and refund credit in one ledger, which is where most groups eventually land and where bolt on products stop working.

How do hidden costs get into the quote?

Stored value quotes go wrong in five places.

• Number of point of sale estates. Two or three till systems means doing the integration two or three times, and older estates often need a middleware layer built first.
• Distributor count. Each partner is a separate format and a separate settlement flow, with its own reconciliation logic.
• Multi entity and multi currency. These change the ledger design rather than adding features to it, and retrofitting them is close to a rebuild.
• Balance migration. Cards are already in customers' wallets and cannot be reissued, so a parallel period with dual authorisation is real project cost rather than overhead.
• Fraud rule administration. Rules that a risk lead can edit with an audit trail cost more than hard coded thresholds, and hard coded thresholds are obsolete by the next holiday season.

Digital Heroes delivery experience puts a first release with the balance ledger, real time authorisation for tills and online, activation, reload, refunds and a liability report by entity at $70,000 to $150,000 over 12 to 18 weeks. A full platform adding distributor feeds, dormancy and escheat reporting by jurisdiction, the fraud engine, franchise settlement and bulk business issuance runs $180,000 to $450,000 across 6 to 12 months.

What separates a build that works from one that fails here?

Working builds treat the ledger as the product. One authoritative record where a card, its funding event, every authorisation attempt, every redemption, every fee and its escheatment state live together is what makes month end a query instead of an investigation. Anything less is three departments each holding a third of the answer.

They migrate balances without a hard cutover. Existing cards keep working because lookups check the new ledger and fall back to the old processor for two to four weeks, with a daily reconciliation report. A cutover weekend on live customer balances is a decision you only make once.

They treat the card number as a bearer instrument even though it is not cardholder data under the Payment Card Industry Data Security Standard. Whoever holds the number can spend it, so access control, logging and interface rate limits should be designed as if it were payment data, and support staff should not be able to browse full numbers freely.

And they settle ownership before kickoff, covering the repository, the database and the cloud accounts. This system holds a regulated liability belonging to your customers, and you cannot end up in a position where changing supplier means migrating live balances under commercial pressure.