Designing Search and Filtering for a 50+ Brand Gift-Card Catalog

A gift-card store with five brands can get away with a simple list. A store with fifty or more cannot. Once the catalog grows past a few dozen brands, denominations, regions, and delivery formats, browsing turns into work — and shoppers start leaving. The challenge is not adding a search box. It is designing search and filtering that matches how people actually shop for digital codes.

Start from the shopper's mental model

Most gift-card shoppers do not arrive with a SKU in mind. They arrive with a person, an occasion, and a budget. "Something for a gamer, around 25 euros, delivered today." Or: "A top-up for my nephew's phone, same country as his number."

That means the catalog has to be organized around intent, not internal inventory codes. The most useful top-level dimensions are usually:

• Recipient / use case: gaming, streaming, music, app stores, prepaid payment, mobile top-up.
• Brand: the platform or service the code is for.
• Denomination: fixed values, ranges, or variable amounts.
• Region: where the code can actually be redeemed.
• Delivery format: instant digital code, email delivery, or physical card.
• Payment method: card, PayPal, crypto, and so on.

If a filter combination returns zero results, the design has failed. Empty results are the catalog's way of telling a shopper to go elsewhere. Every filter should show counts, and the interface should make it easy to relax one constraint at a time.

Search is a ranking problem, not a matching problem

Substring matching is not enough. A shopper who types "PlayStation" might mean the store, a subscription, a wallet top-up, or a game. A shopper who types "Roblox" might be buying for a child and need the region-safe option, not the cheapest one.

A practical ranking approach:

1. Exact brand matches first. If the query matches a brand name, show that brand's products before anything else.
2. Synonyms and common misspellings. Gamers search for "PSN", "PS Plus", "Playstation", and "Sony". All of them should land in the same place.
3. Category matches second. "Streaming" should surface Netflix, Spotify, Disney+, and similar services — not a single product page that happens to contain the word.
4. Popularity as a tiebreaker. When several products match equally well, the ones people actually buy and redeem successfully should rank higher.

Keep the search index small and fast. Gift-card catalogs change slowly compared to most e-commerce: brands, denominations, and regions are relatively stable. That makes it practical to precompute the index and serve search from a cache, with a short TTL for price and availability changes.

Facets need guardrails

Faceted filtering looks simple until the combinations explode. Fifty brands times six denominations times ten regions times three formats is thousands of theoretical combinations, most of them empty. Three guardrails help:

• Only show facets that narrow the current result set. If every remaining product is a digital code, hide the format facet.
• Disable, don't hide, impossible values — or hide them with a count of zero. Shoppers should understand why a combination does not exist.
• Treat region as a first-class filter, not an afterthought. A code that cannot be redeemed in the shopper's country is not a bargain; it is a support ticket. Region should be prominent, persistent, and set early — ideally before the shopper picks a denomination.

Sorting also matters more than it first appears. "Price: low to high" is the default on many stores, but for gift cards the most useful sorts are often "most popular", "best for gifting", and "newest". A 10-euro card is not better than a 50-euro card just because it is cheaper — the shopper's budget decides that.

Denominations are data, not decoration

Gift-card denominations deserve their own data model. A product can have fixed values (10, 25, 50), a range with a minimum and maximum, or a mix. The UI has to handle all three without confusing the shopper:

• Show the full list of fixed denominations, with the most popular one preselected.
• For variable amounts, show the allowed range and validate immediately. Rejecting an out-of-range amount at checkout is a failure of the catalog, not the shopper.
• Display the total price including fees before the shopper reaches checkout. Hidden fees are the fastest way to lose trust in a prepaid store.

Currency adds another layer. If the store lists prices in several currencies, the catalog must be explicit about which currency a denomination is sold in, and which currency the recipient's platform expects. A 25-euro code and a 25-dollar code are not interchangeable.

Performance and freshness

Catalog pages are read-heavy, so they are a good fit for caching and static generation. But availability is not static: a denomination can sell out, a region can be suspended, or a supplier can pause a brand. The design needs a clear split:

• Static: brand descriptions, category pages, denomination lists, help content.
• Dynamic: price, stock/availability, and region eligibility, fetched per product or per result set.

A common pattern is to render the catalog shell from cache and hydrate availability in a second, smaller request. The page feels instant, and the availability data stays fresh. If the availability request fails, the page should show a clear "availability unknown — check before buying" state rather than silently selling something that may not exist.

Measure what matters

The metrics that tell you whether catalog search works are behavioral, not technical:

• Search-to-product rate: what share of searches lead to a product view?
• Zero-result rate: which queries return nothing, and what should they have returned?
• Filter usage: which facets do shoppers actually use, and which ones are decoration?
• Support contacts per order: a spike in "wrong region" or "wrong denomination" tickets usually means the catalog let someone buy the wrong thing.

Log the queries that return zero results. They are the cheapest source of catalog improvements you will ever get: each one is a shopper telling you exactly what they wanted and did not find.

A worked example

Consider a shopper buying a gaming gift card as a last-minute birthday present. The ideal path is: search "gaming" → filter to their region → pick the brand the recipient plays on → pick a denomination in budget → see the price and delivery time → check out. Five steps, no dead ends, no surprises about region or fees.

That path only works if the catalog data is clean: one canonical record per brand, consistent region codes, explicit denominations, and honest availability. Most catalog search problems are data problems wearing a UI costume.

You can see how this plays out in practice by browsing a large real-world catalog — for example, Kadokey's gift-card store lists dozens of brands across gaming, streaming, prepaid payment, and mobile top-up, so the filter and region choices above are not hypothetical. The lesson generalizes: the bigger the catalog, the more the data model matters, and the less a search box alone can save you.

Checklist

• Organize around shopper intent: recipient, occasion, budget, region.
• Rank search by brand, then category, then popularity.
• Show facet counts; never dead-end on an empty combination.
• Make region prominent and persistent.
• Model denominations explicitly: fixed, variable, and mixed.
• Show total price early, fees included.
• Cache the catalog shell; hydrate availability separately.
• Log zero-result searches and fix the top ones weekly.

Get those right, and a 50-brand catalog feels as simple as a five-brand one — which is exactly the point. For a sense of the scale involved, the full catalog at Kadokey is a useful reference for how many brands, denominations, and regions a modern digital gift-card store has to organize.