Gift cards that redeem correctly every time:
and store credit that never gets spent twice
A gift card or store credit balance looks like a simple number, until two checkouts try to spend the same balance at the same moment. Or a partial redemption leaves the remaining balance wrong because the deduction wasn't handled atomically.
What it is
A gift card and store credit system tracks a monetary balance tied to a customer. That balance might come from a purchasable gift card, a return refunded as credit instead of cash, or a referral reward. The system lets that balance be applied at checkout correctly, in full or in part, with the remainder carried forward. It never gets spent twice, even if two checkout attempts happen close together. The correctness problem is the same class as any balance or stock system, atomic deduction under concurrency, just applied to money instead of inventory.
We’ve verified this exact kind of guard before launch. A margin check against 864 orders on the marketplace we’re launching found zero processed below cost. The same discipline has to apply to a credit balance, where a bug in deduction logic is a direct, measurable financial loss, not a cosmetic bug.
When you need this (and when you don’t)
You need a custom build when your platform’s native gift card feature doesn’t cover your actual use case. Store credit issued automatically from returns points to a custom build. So does credit earned through a referral program, or a balance that needs to interact correctly with other discounts and promotions at checkout. It’s also worth building properly once gift cards or credit are a meaningful share of revenue. A bug at that point is a real financial exposure, not a minor inconvenience.
You don’t need a custom system if your platform’s built-in gift card feature already covers your use case cleanly. Shopify’s native gift cards are a good example. Building a parallel system in that case adds risk and maintenance for no real benefit.
How we build it: stack, components, integrations
Every balance lives in PostgreSQL, with deductions wrapped in a transaction that locks the specific balance row for the duration of the checkout. Two simultaneous attempts to spend the same gift card can’t both succeed. One correctly sees an insufficient or already-spent balance. Partial redemption deducts exactly the amount used and leaves the correct remainder. That gets recorded as a line item in the balance’s history, so a customer or your support team can always see exactly what happened to it.
Issuance integrates with however credit originates in your business. That could be a purchased gift card delivered as a code by email, or a return processed as store credit instead of a refund. It could also be a referral reward issued automatically when a referred order completes. At checkout, the balance applies before other discount logic runs. It’s calculated against the actual order total, so a gift card can’t be stacked in a way that produces an incorrect final price.
What to watch: risks, cost of ownership, vendor lock-in
Gift card and store credit fraud is a known pattern. Stolen card numbers get used to purchase gift cards that are then resold, or used before a chargeback reverses the original purchase. A fraud check on gift card purchases specifically, not just physical-goods orders, matters because of this. Expiry rules, where your market or policy requires them, need to be enforced consistently and disclosed clearly. Unexpected expiry is a common source of customer complaints, and in some jurisdictions, a legal issue too.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Issuance and redemption | from $2,500 | Balance tracking, checkout integration | 3 to 4 weeks |
| Credit from returns and referrals | from $5,000 | Automatic issuance from multiple sources | 4 to 6 weeks |
| Full system with expiry and reporting | from $7,500 | Full build with expiry rules and financial reporting | 6 to 7 weeks |
Running cost is usually $10 to $25 a month in hosting. The real ongoing cost is the liability of outstanding balances, which is a finance decision, not an infrastructure one.
What this pairs with
This pairs with loyalty and referral program, since referral rewards often issue as store credit. It also pairs with subscription box commerce, where credit can offset a skipped or canceled cycle. See the e-commerce service page for package details. For real balance-sensitive systems we’ve verified in production, see the sports nutrition sales ×2.7 case study.
Worried a gift card or credit balance could be spent twice in your current setup? Get in touch and we will check your checkout logic first.
FAQ
How much does a gift card and store credit system cost?
From $2,500 for issuance and redemption integrated into an existing checkout. $5,000 to $8,000 is typical when the build adds expiry rules, referral-based credit issuance, or a dedicated gifting flow.
How long does it take?
3 to 7 weeks, depending on whether your platform's native gift card feature covers part of this, or a fully custom balance system is needed.
What is the stack?
PostgreSQL for balance tracking, with row-level locking on every deduction so concurrent checkouts can't both spend the same balance. A FastAPI endpoint is what checkout calls to apply, validate, and deduct a balance before the payment step.
Who owns the gift card and credit data?
You. Balances, issuance history, and redemption records live in your own database. That matters for financial reconciliation and audit, not just for the shopper experience.
Who maintains it after launch?
Balance logic runs unattended. Issuing bulk gift cards for a promotion, or adjusting a balance manually, is designed to be done by your team through the admin tools.