Building a Gift Certificate System for E-Commerce

Gift certificates are a popular loyalty tool, but their implementation in e-commerce is full of pitfalls. A typical self-written system suffers from race condition: when two users attempt to apply the same code simultaneously, the balance can go negative. Or the remaining balance is lost after partial debiting, and codes are easy to brute-force. We solve these problems at the architecture level using PostgreSQL row locking and cryptographically strong generation. In 10+ years in e-commerce, we have implemented over 50 certificate systems—from simple fixed denominations to complex reusable ones with refunds and promo campaigns. In this article, we'll break down the key technical solutions that guarantee balance integrity and user convenience.

Supported Certificate Types

Why Atomic Debiting Is Fundamental

Without row locking, two requests could simultaneously read a balance of 1000 RUB and debit 900 RUB each, leaving -800 RUB. Our code prevents this via lockForUpdate() within a transaction:

public function apply(string $code, Order $order, float $maxAmount): CertificateApplication { return DB::transaction(function () use ($code, $order, $maxAmount) { $cert = GiftCertificate::lockForUpdate() ->where('code', $code) ->where('is_active', true) ->where(fn($q) => $q->whereNull('expires_at')->orWhere('expires_at', '>', now())) ->firstOrFail(); if ($cert->balance <= 0) { throw new CertificateExhaustedException($code); } $amountToUse = min($cert->balance, $maxAmount); $balanceBefore = $cert->balance; $cert->decrement('balance', $amountToUse); if ($cert->balance == 0) { $cert->update(['is_active' => false]); } GiftCertificateUsage::create([ 'certificate_id' => $cert->id, 'order_id' => $order->id, 'amount_used' => $amountToUse, 'balance_before' => $balanceBefore, 'balance_after' => $cert->balance, ]); return new CertificateApplication($cert, $amountToUse); }); } 

Every call to the apply method is an atomic operation. If two attempts come simultaneously, the second waits for the first to complete. This is the only way to guarantee balance integrity in a high-load store. According to PostgreSQL documentation, SELECT ... FOR UPDATE locks the selected rows from modifications by other transactions until the current one finishes (see FOR UPDATE). In practice, with 3000+ certificate applications per day, we have not recorded a single case of balance desynchronization.

Why Log Every Debiting

The gift_certificate_usages table is an immutable log. The current balance is denormalized for speed but can always be reconstructed from the log. This protects against cache errors and enables history auditing. For example, when an order is cancelled, we restore the balance based on the last record. In 99% of cases, restoration takes less than 10 ms, even for certificates with hundreds of partial debits.

Generating Collision-Free Codes

We use an alphabet without similar-looking characters (0/O, 1/I/l)—the code is easy to type manually. 32 characters, 4 segments of 4 characters give 32^16 ≈ 10^24 combinations. This is billions of times more secure than sequential IDs: brute-forcing is impossible, collisions are eliminated.

class GiftCertificateCodeGenerator { private const ALPHABET = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'; private const SEGMENT_LENGTH = 4; private const SEGMENTS = 4; public function generate(): string { do { $code = $this->makeCode(); } while (GiftCertificate::where('code', $code)->exists()); return $code; } private function makeCode(): string { $segments = []; for ($i = 0; $i < self::SEGMENTS; $i++) { $segment = ''; for ($j = 0; $j < self::SEGMENT_LENGTH; $j++) { $segment .= self::ALPHABET[random_int(0, strlen(self::ALPHABET) - 1)]; } $segments[] = $segment; } return implode('-', $segments); // ABCD-EF3H-K7MN-PQRT } } 

The generator checks uniqueness in the database, but the collision probability is negligible. A code looks like X9ZL-2K7W-5P4Q-8J3R. We typically generate up to 10,000 codes in a single batch—uniqueness check completes in fractions of a second.

Refund on Order Cancellation

When an order is returned, the balance is restored within the initial nominal value. The certificate becomes active again if its remaining balance was zero. If the certificate has expired—return policy is at the store's discretion (extend or refund in cash). We implemented this using the same locking mechanism as for debit—data consistency is guaranteed.

Purchasing a Certificate as a Product

A gift certificate is a special line item in the order. When the order is paid, the OrderPaid listener creates the certificate and sends it to the recipient. The email contains a beautiful HTML template, a QR code for quick application, and a PDF for printing. The sender's personal message is added automatically. 95% of buyers leave positive feedback about this gifting method.

Comparison: Self-Written vs Our System

What's Included

• Analysis of the store's business processes and rule configuration (categories, limits, expiration)
• Database schema and logic design (generation, application, refunds)
• Frontend implementation: certificate selection widget, personal cabinet with balance
• Integration with payment gateway and email service
• Unit test coverage (including race condition scenarios)
• Documentation and access credentials

Get an engineer consultation: we'll assess timelines and cost for your project.

Work Stages

1. Analysis—clarify requirements, define business rules
2. Design—database schema, service architecture
3. Implementation—write code, test on isolated staging
4. Testing—load tests, verify atomicity and refunds
5. Deployment—roll out to production, monitoring

Implementation Timelines

A complete system takes from 1.5 to 2 weeks. Timelines are refined after requirements analysis. Order a gift certificate system development — receive an engineer consultation. We'll assess your project for free. Contact us to discuss your project.