A CTO's look at the engineering that turns a single tap into a gift delivered instantly, anywhere in the region.
Someone opens our app. They find a brand their friend loves. They tap, they pay, and within seconds the gift card is in the recipient's inbox. The whole experience takes less than two minutes and feels effortless.
Behind those two minutes is a system that connects us to hundreds of brands across six countries, handles real-time inventory and denomination validation, processes payments, issues unique codes, and delivers them across email, SMS, and WhatsApp — all while maintaining the transactional integrity that means if anything fails, nobody loses money.
This is a story about what it actually takes to make something feel simple.
A gift card looks like a code. Under the hood, it's an agreement between three parties: us, the brand, and the customer. The brand has allocated a pool of value. The customer has paid for a specific denomination. We hold the code — the proof of that agreement — and are responsible for delivering it intact and on time.
Every brand partner has different integration patterns. Some provide APIs with real-time code issuance. Others use batch-provisioned code pools that we manage on our side. Some operate in single currencies; others need multi-currency handling with live exchange rate validation. Our integration layer abstracts all of this so that the product and customer experience is uniform regardless of the brand's underlying model.
"The complexity isn't in any single integration. It's in making 500 different integrations feel like one coherent system."
The hardest engineering problem in gift cards is the distributed transaction. When a customer pays, three things need to happen atomically: the payment must be captured, the code must be issued (or reserved), and the delivery must be initiated. If the payment succeeds but code issuance fails, we owe the customer a refund. If code issuance succeeds but payment fails, we've given away value for free.
We use an outbox pattern with idempotent retries at every integration boundary. Each step writes its intent to a durable log before acting. If a step fails and retries, it checks whether the downstream action has already occurred before attempting it again. This makes every operation safe to retry without causing duplicate charges or duplicate code issuance.
On a normal day, we process thousands of transactions. On peak days — Eid, Valentine's Day, major corporate campaigns — that number can spike 10–15x with less than an hour's notice. Our architecture is built to handle this without human intervention:
Most of the engineering in this system exists to handle cases that users will never see: the brand API that returns a 200 with an error body, the denomination that was available at checkout but sold out before issuance, the customer whose email bounces but whose WhatsApp needs to catch the gift instead.
When we do this work well, nothing happens. The customer gets their gift card in seconds and thinks nothing of it. The brand partner sees a clean integration with no support tickets. The only evidence that the system did something complex is the absence of problems.
That's what I find most interesting about this kind of engineering: the measure of success is silence. The teams that build infrastructure, reliability, and integration systems are working toward a world where nobody notices their work — because everything just works.
That's the goal. And it's worth building carefully.