Gift Card and Stored Value Platforms: Stay on Givex, or Build Your Own Ledger?

When is off the shelf genuinely the right call here?

If your outstanding gift card liability is under roughly $2M, 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, buy. Givex and Paytronix are genuinely solid at that scale, the till integrations already exist, and a build is an expensive route to the same place. Put the difference into stores.

Buy also if nobody in finance is currently asking for a jurisdiction breakdown. The dormancy, breakage and escheat engine is the most expensive single component in a full platform at $30,000 to $60,000, and without a buyer for it the case for building collapses to the authorisation layer alone, which the incumbents already do competently. That is a real and common situation and it deserves a plain answer rather than a discovery workshop.

Keep the card production and fulfilment vendor whatever you decide. Plastic, packaging and rack distribution are not software problems and rebuilding them buys nothing. Keep the distribution networks too, meaning Blackhawk Network or InComm if you sell through retail racks, since that is a commercial relationship rather than a piece of engineering.

The test that settles it: can your controller produce outstanding liability by entity and by state of issuance from a report rather than a reconciliation. While the answer is yes, or while nobody needs to ask, you have not outgrown what you can buy.

When does a custom build actually pay off?

The signals are financial and they usually arrive with an auditor attached.

Outstanding liability is over roughly $10M and finance cannot produce a jurisdiction breakdown on demand. Month end reconciliation between the processor's liability figure and the point of sale journal takes days rather than an afternoon, and the answer at the end is an estimate. You sell through distributors and reconciliation is manual. Franchise settlement disputes are a recurring meeting. You have been hit by card draining and your only tool is a goodwill refund. Or stored value, loyalty points, store credit and refund credit need to sit in one ledger, which is where every multi brand group eventually lands and where bolt on products stop working entirely.

The structural cause is that no packaged product holds one authoritative ledger where a card, its funding event, every authorisation attempt, every redemption, every fee and its escheatment state live together. Distribution sits with a network, till integration sits with a stored value product, and the general ledger sits in NetSuite or QuickBooks. Each is competent at its own slice. The reconciliation between them is a person.

The escheatment point is the sharpest one and the least forgiving. Obligations depend on the state of issuance, or in some cases the purchaser's address, 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 unclaimed property examination, which is the worst moment to discover it. Confirm your own position with unclaimed property counsel rather than from a vendor datasheet or from this page.

How do they compare on the things that matter in this industry?

• Jurisdiction fidelity. Packaged products rarely carry issuing entity, issuing location and a dormancy clock stamped on the card at creation with the fidelity an examination expects. Deriving it from sales data afterwards is your next audit finding, and it is the difference no feature grid shows.
• Authorisation edge cases. The common path is well handled everywhere. The cost appears on the uncommon path: partial redemption, split tender across a card and a payment method, a tip added after authorisation, a refund to a card since merged into a digital wallet, or one call that checks both a stored value balance and a loyalty balance. Each of those becomes a change request against someone else's roadmap.
• Offline policy. Whether a disconnected till declines stored value or authorises to a floor limit is a commercial decision, and it should be configurable per channel and per store so you can tighten it where losses appear. Products ship one behaviour and you live with it.
• Fraud instrumentation. Product level tools mostly watch redemption velocity, which fires after the money has gone. The loudest early signal is balance enquiry behaviour, because attackers poll continuously to detect activation, and acting on that requires owning the ledger.
• Rule editability. Draining patterns shift every holiday season, which is exactly when nobody has time to raise a support ticket. Rules your risk lead can edit with an audit trail are worth more than better rules you cannot change.
• Exit under pressure. This system holds a regulated liability, and the cards are already in customers' wallets. Ask any vendor what a migration out looks like before you sign, because you cannot be in a position where changing supplier means moving live balances in a hurry.

What does total cost of ownership look like at your scale?

From Digital Heroes delivery experience, a first release covering the balance ledger, real time authorisation for the till and the website, activation, reload, refunds and voids, and a liability report by entity runs $70,000 to $150,000 over 12 to 18 weeks. A full platform adding distributor activation feeds, dormancy and escheatment by jurisdiction, the fraud engine, franchise settlement and bulk corporate issuance runs $180,000 to $450,000 phased over 6 to 12 months.

Card volume is not the driver people expect, since a ledger handles a million cards as easily as a hundred thousand. What sets the number is how many places have to ask the ledger a question. Each point of sale estate is $22,000 to $45,000, with older estates at the top of that range because they often need a middleware shim first. Each distributor adapter is $18,000 to $35,000. Balance migration with a dual authorisation period is $25,000 to $55,000.

A worked shape: a restaurant group with 210 locations of which 60 are franchised, roughly $14M outstanding, two point of sale estates after an acquisition, several states, an ecommerce channel and existing balances to move, totals $390,000, or $437,000 with a 12 percent contingency, across about eleven months. That contingency is not padding, because at least one state's treatment usually turns out to differ from what finance believed.

Annual running cost is 18 to 25 percent of build, so roughly $79,000 to $109,000 on that platform. Add unclaimed property rule maintenance at $12,000 to $30,000 a year, point of sale version upgrades at $8,000 to $25,000 per estate per major version, fraud rule tuning at $10,000 to $25,000, hosting and access review at $12,000 to $30,000, and audit support at $10,000 to $25,000. Be honest about that line, because a stored value ledger with no funded owner drifts back into exactly the state you were leaving.

What does the hybrid look like, and when is it the honest answer?

The pure hybrid is common here and it is a serious option rather than a hedge. Keep the incumbent running authorisation and till integration, and build only the finance layer above it: a shadow ledger that ingests every activation, redemption, reload and adjustment from the processor, stamps issuing entity, issuing location and jurisdiction at the moment of sale from your own sales data, and produces liability by entity and jurisdiction, aged balances, breakage recognition as journal entries and a per state escheat file.

That works because the finance requirement and the operational requirement are separable. The processor keeps doing the thing it is genuinely good at, meaning a low latency balance authorisation at a till with a queue behind it. You own the record your auditor asks for. It costs a fraction of a full platform, it disrupts no store, and it removes the four day monthly reconciliation, which is usually the loudest pain in the room.

The other hybrid worth naming is the phasing inside a full build. Keep production and fulfilment external. Scope release one to one entity, one point of sale estate and one country, deferring distributors and franchise settlement. Report from the finance system you already have rather than building a second reporting stack. And defer the fraud engine by exactly one phase, not two: instrument the ledger from day one so activation and enquiry signals are being recorded, then write the rules against three months of your own data. Rules built against imagined patterns cost more and work worse.

One thing not to defer is the offline policy. Deciding whether a disconnected till declines stored value or authorises to a floor limit takes an afternoon with operations and finance in the room, and deciding it late costs weeks of rework in the authorisation engine.

Which should you choose, by operator size and stage?

Under $2M outstanding, one or two states, one till system, no retail racks: buy. Givex or Paytronix, and spend the difference on stores. Nothing else here applies to you yet.

Any liability size where finance has never asked for a jurisdiction breakdown: buy. The escheat engine is the expensive component and it has no internal sponsor, so a build would be sold rather than needed.

Roughly $2M to $10M outstanding, one point of sale estate, a few states: buy the operational platform and build the shadow ledger for finance. That combination costs a fraction of a full build and answers the question that actually gets asked.

Over $10M outstanding across several states with two or more till estates: build. Start with the ledger and the authorisation engine, because nothing else can be built until a hold and a capture behave correctly under a dropped connection, and expect the chief financial officer to be paying for the escheat engine that lands in the second half.

Franchised groups: build the settlement layer, and do it after redemption posting is trusted rather than alongside it. Every franchise redemption is an inter entity settlement with real money attached, and doing it in spreadsheets is where groups lose both money and goodwill, because disputes arrive months later with no supporting detail.

Multi brand groups running loyalty, store credit and refund credit alongside gift cards: build, and decide the single ledger question before the first schema is written. Multi entity and multi currency change the ledger design rather than adding to it, which makes them the one decision you genuinely cannot defer to month eight.

If you would rather someone argued with your brief than agreed with it, Digital Heroes contracts through India LLP, US LLC and UK LTD entities, so the agreement and the intellectual property assignment sit under law your own advisers already read. Nothing about that commits you to the build.