Gift Card and Stored Value Platforms: Who Actually Owns That Unspent Balance?

Why stored value breaks the point of sale and the general ledger at the same time

A gift card looks like a marketing programme until the first time your auditor asks for a balance roll-forward by state of issuance. Then it becomes what it always was: a pool of other people's money that you are holding, that authorises in real time at a till where a queue is forming, that a criminal is actively trying to drain, and that some states expect you to remit if it goes unused. Three different departments each hold one third of the problem and none of them owns the object.

The scene that convinces most CFOs is the month-end one. Finance is reconciling a liability number from the card processor against sales in the POS journal, and the two disagree by an amount nobody can explain because a batch of cards sold through a supermarket rack activated three days after they were purchased, a franchise location redeemed against a balance the central system had already written off, and a promotional card issued by the marketing team was never coded as a liability at all. The reconciliation takes four days a month, and the answer at the end is an estimate.

The tools involved are usually a processor like Blackhawk Network or InComm for distribution, a POS integration through Givex or Paytronix, and QuickBooks or NetSuite underneath. Each is competent at its own slice. None of them holds one authoritative ledger where a card, its funding event, every authorisation attempt, every redemption, every fee, and its escheatment state live together. That ledger is the product, and it is why this ends up being financial infrastructure rather than retail software.

Authorisation at the till is a latency and edge case problem, not a lookup

The naive model is: read the card number, ask for a balance, deduct. The real one has partial redemption, split tender across a card and a payment method, a tip added after authorisation in restaurants, voids and returns that must reverse to the original instrument, a franchise store on a flaky connection, and a queue of eight people behind the customer.

Two behaviours decide whether the system is usable. First, authorisation must be a two-phase operation, a hold then a capture, not a single deduct. Without it, a dropped connection between the till and the platform leaves you guessing whether the customer's $50 was taken, and the store manager resolves that guess in the customer's favour every time. Second, you need a defined offline policy. Not an accident, a policy. 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 you a bounded amount of fraud. Pick deliberately, write the number down, and make the floor limit configurable per channel.

Processor-led platforms handle the common path well. Where they get expensive is the uncommon path: a card partially redeemed in one country and topped up in another, a refund to a card that has since been merged into a digital wallet, or an authorisation that must check both a stored value balance and a loyalty points balance in one call. Every one of those becomes a change request against someone else's roadmap.

Card draining is the fraud that shows up as a customer service complaint

The pattern is well known and widely reported: cards are lifted from a retail rack, the numbers and any scratch-off codes are recorded, the packaging is restored, and the card goes back on the rack. 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, often into another stored value instrument or a marketplace purchase. Your first signal is an angry customer at a service desk with a receipt for a card that is already empty.

Product-level fraud tools mostly watch redemption velocity, which fires too late. What actually helps is instrumenting the whole lifecycle, and that means owning the ledger. Concretely: score the interval between activation and first redemption, because a card drained inside five minutes of activation in a channel different from the one it was sold in is a near-certain tamper case. Rate limit balance enquiries per card and per source, since attackers check balances continuously to detect activation, and that enquiry pattern is the loudest signal available before the money moves. Detect enumeration by watching failed lookups against number ranges. Hold high-value online redemptions for a short review window when the card has never been used before and the delivery address is new. And crucially, log the decision, because when you refund a drained card as a goodwill gesture you want a data set that tells you which retail racks are being hit.

Fraud rules of this kind are commercial policy, not engineering constants. They should be editable by your risk lead in an admin screen, with an audit trail, because the pattern shifts every holiday season.

Breakage and escheatment: the liability finance is managing by hand

Two rules shape the money. The federal Credit CARD Act of 2009 sets floors for consumer gift cards, including that funds cannot expire earlier than five years from the date value was last loaded and that inactivity fees are tightly constrained. On top of that sit state unclaimed property laws, which vary considerably: some states exempt gift cards entirely, some require remittance of the unredeemed balance after a dormancy period, and several require cash redemption of small remaining balances on request. Delaware has historically been aggressive on unclaimed property generally. Get your specific position from unclaimed property counsel, not from a vendor datasheet and not from this page.

The software consequence is precise and unforgiving: escheatment obligations depend on the state of issuance, or in some cases the address of the purchaser, at the moment of sale. If your ledger does not record where each card was sold and by whom, you cannot produce a defensible report later, and the reconstruction is expensive. Most groups discover this during their first audit.

What a custom build does: every card carries its issuing entity, issuing location, jurisdiction, funding source and dormancy clock from creation. Breakage recognition runs as a scheduled process against a documented policy your auditor has signed off, producing journal entries rather than a memo. Dormancy tracking is per jurisdiction with its own period. Then the reports you actually need come out of one query: liability by entity and jurisdiction, aged balances, breakage recognised in period, and a per-state escheat file. What was four days a month becomes a report your controller runs.

Distributors, franchises and B2B bulk issuance

The complexity that surprises people is not the consumer card, it is everything around it. Third party distributors send activation files, sometimes in real time and sometimes as a batch that arrives late, and each distributor has its own format and its own settlement terms. Franchise locations redeem centrally issued value and must be reimbursed, which is an inter-entity settlement problem with real money and real disputes. Corporate and B2B orders arrive as a spreadsheet of 4,000 cards with individual recipient names for an employee reward programme, and someone is currently doing that by hand in December.

What a custom build does: distributor integrations as pluggable adapters with per-partner reconciliation, so a mismatch is flagged the next morning rather than at quarter end. Franchise redemption produces an automatic settlement entry against the franchisee's account at the agreed rate. Bulk issuance is a self-serve corporate portal with an approval step, CSV upload, per-recipient delivery, and its own invoice. And digital delivery is treated as a first class channel, because a code delivered by email is a bearer instrument sitting in an inbox and needs its own controls.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape is consistent. A first release with the balance ledger, real time authorisation for POS and ecommerce, activation and reload, refunds and voids, and a liability report by entity runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding distributor activation feeds, multi-jurisdiction dormancy and escheat reporting, the fraud engine, franchise settlement and B2B bulk issuance runs $180,000 to $450,000 phased over 6 to 12 months.

What drives cost up specifically here: the number of POS estates, because a group running two or three different till systems is doing the integration two or three times, and older estates often need a middleware shim. Distributor count, since each one is a separate format and settlement flow. Multi-currency and multi-entity, which changes the ledger design rather than adding to it. And migration of existing balances, which is genuinely delicate, because those cards are in customers' wallets and cannot be reissued.

What keeps cost down: one entity, one POS, one country for release one, with distributors and franchise settlement deferred to phase two. Gift card numbers are not cardholder data under PCI DSS, which spares you a scope you might expect, but treat them as bearer instruments anyway and design the access controls accordingly.

When buying is the right answer

Buy if your outstanding liability is under roughly $2M, you operate in one or two states, you have a single POS estate, and you are not selling through third party retail racks. Givex and Paytronix are solid at that scale, the integrations already exist, and a build would be an expensive way to arrive at the same place.

Build when two or more of these are true. Your outstanding liability is over $10M and finance cannot produce a jurisdiction breakdown on demand. You sell through distributors and your reconciliation is manual. You run franchises and settlement disputes are a recurring meeting. You have been hit by card draining and your only tool is a goodwill refund. Or your card programme needs to sit in the same ledger as loyalty points, store credit and refund credit, which is where every group eventually lands and where bolt-on products stop working entirely.

How to choose a developer for a stored value build

Ask them to describe the authorisation flow including the failure cases: connection lost after hold, refund to a card that has been transferred to a wallet, and split tender where the card covers part of a taxed total. If the answer does not include a two-phase hold and capture, they have built a balance lookup and you will find out at Christmas.

Ask how they model jurisdiction. The correct answer records issuing entity, issuing location and dormancy clock on the card at creation, not derived later. Anyone who plans to reconstruct it from sales data is proposing your next audit finding.

Ask what they have integrated on the POS side, by name and version. Toast, Oracle Micros, Aloha, NCR and Lightspeed are different problems with different offline behaviour, and experience with one does not transfer cleanly to the others.

Ask who owns the code, the database and the cloud accounts, and settle it in writing before kickoff. This system holds a regulated liability and you cannot be in a position where changing supplier means migrating live customer balances under pressure. At Digital Heroes the client owns the repository from the first commit.