How We Built Instant Gift-Card Delivery: Lessons from a Digital Goods Store

A few years ago I ended up helping run a store that sells gift cards, prepaid codes and mobile top-ups from more than 56 brands — Steam, PlayStation, Netflix, paysafecard and the rest. Selling digital goods sounds like the easiest e-commerce problem on earth: no warehouse, no shipping labels, no logistics. In practice the entire customer experience lives or dies on a single metric: how fast the code lands in the buyer's hands.

Here are the lessons we learned while building Kadokey's delivery pipeline — the system that turned "instant" from a marketing word into an actual property of the checkout.

1. Codes are inventory, not email attachments

Our first version treated redemption codes as plain strings attached to order confirmation emails. It worked until two customers were emailed the same code within seconds of each other, and both tried to redeem it. One got an error, the other got a gift card they technically didn't own.

Now every code lives in an encrypted vault table with a state machine: available, reserved, delivered, refunded. Reservation happens inside the same database transaction as the order commit, so a code can never be handed to two buyers. Simple concurrency control, but it's the difference between a store and a support inbox full of "code already redeemed" tickets.

2. Delivery must be synchronous, not a background job

Early on, code delivery ran through a worker queue that processed orders every few minutes. That felt fast on paper. In reality, customers who buy a game key at 11pm check their inbox at 11:00 and 15 seconds, and if the code isn't there, they open a support ticket at 11:01.

The fix was to move delivery into the payment-callback path itself: the moment the payment processor confirms success, the code is reserved, rendered into the confirmation page, and pushed to the buyer's email. Idempotency keys on the callback mean duplicate notifications never double-deliver. Median delivery time went from minutes to seconds.

3. Fraud prevention is the real engineering problem

Digital codes can't be "returned" — once a code is redeemed, it's gone. That makes digital goods stores a magnet for card testers and account takeovers. We layered defenses:

• Velocity checks — how many orders per card, IP, and device per hour.
• Pattern flags — mismatched billing and IP geolocation, disposable email domains, and impossible order sizes.
• Human review queues — suspicious orders hold for manual review instead of auto-delivering, and that one-minute delay on a tiny fraction of orders cut fraud losses dramatically.

4. Crypto payments changed the economics

Chargebacks are brutal on digital goods because the seller has nothing to repossess. Accepting crypto removed the entire chargeback surface, and customers who pay with crypto get their codes fastest since there's no card authorization hold to wait on. It's a genuine fit for this product category, which is why we give crypto buyers 12% off their first order with the code CRYPT12.

5. Instant only counts if the code works

Speed means nothing if the code fails at redemption. We now validate batches against supplier APIs before listing, and any invalid code triggers an automatic replacement without the customer having to ask. Delivery SLA is measured end-to-end — from payment confirmation to a working code in the buyer's hands.

Takeaway

Building instant delivery for digital goods is less about raw speed and more about trust engineering: concurrency-safe inventory, synchronous fulfillment, layered fraud checks, and payment methods that don't punish the seller. Get those right and the store practically runs itself.

If you want to see what that stack looks like from the customer side, check out Kadokey — 56+ brands with instant delivery, and CRYPT12 still gets you 12% off your first crypto order.