Why we bundle three card-recognition engines instead of one

Every card-shop platform's card-scanner demo looks the same. Phone camera over a card, 300-ms pause, set name and rarity appear, tap to add to inventory. The demo works on a Near Mint Charizard from the 151 set with good lighting. Most cards are not Near Mint Charizards from the 151 set with good lighting.

In production — at a buylist counter with 500 cards to intake, or a customer scanning their binder from their phone in low light — card recognition breaks down in three distinct ways, each of which needs a different technical approach. Using one engine for all three cases is how you end up with tooling that tests well and fails in the shop.

Storefront Pro bundles three engines: TinEye, Ximilar, and our own in-house TCG engine. Every merchant gets access to all three. This post explains why.

The three problems dressed up as one

Problem 1: Identify which specific printing this card is. A Lightning Bolt exists in 30+ printings across 20+ sets. The card in the customer's hand is one of them. The wrong printing is the wrong SKU, the wrong price, and the wrong listing — a mistake that scales badly when staff are processing dozens of cards per minute.

Problem 2: Verify this specific card matches a reference photo — duplicate detection, authenticity checks, grading-slab comparisons. Is this the same physical card that sold on eBay last week? Is this a proof, a proxy, a counterfeit?

Problem 3: Handle messy real-world scans — angled shots, glare, partial obscuration, non-English prints, sleeved cards, poor lighting. The 80% of scans that aren't the demo case.

These aren't the same problem. They use different algorithms, different training data, different speed/accuracy tradeoffs. One engine optimised for all three is worse at each than three engines optimised for one.

What each engine is actually good at

TinEye is a reverse-image-search pioneer with one of the largest indexed image databases in the world. Built by Idée Inc, it powers image verification, stock-photo search, and (critically for us) pixel-accurate matching across known reference images. On a card scan, TinEye excels at Problem 2 — verifying that a card matches a specific reference photo, which matters for graded-card authentication, for duplicate detection in buylist submissions, and for catching substituted cards during trade-in fraud checks.

TinEye is not optimised for 'which Lightning Bolt printing is this.' It's optimised for 'is this the same image.' Use it for the right job and it's unbeatable; use it for the wrong job and it under-performs cheaper alternatives.

Ximilar is a visual-AI platform with a dedicated collectibles-and-trading-cards product line. They've built ML classifiers specifically for card identification, grading visual-condition estimation, and slab recognition. Their strength is Problem 3 — messy real-world scans. Non-English prints, sleeved cards, imperfect lighting, partial obscuration: Ximilar's ML models handle these cases more robustly than algorithmic reverse-image approaches because they were trained on exactly these kinds of real-world inputs.

Their pricing is usage-based (per-API-call), which makes them excellent for high-accuracy one-off lookups and less ideal for running every scan through their engine on a busy intake day. Right tool for the right volume.

Our in-house TCG engine is built around the specific catalogue problem — Problem 1. It knows the full set list for 70+ TCGs, understands finish treatments (foil, etched, alternate art, showcase), handles language variants, and maps ambiguous matches against current inventory and buylist pricing to surface the most likely match weighted by 'is this a card you're likely to be scanning.'

It's fastest for high-volume intake (staff scanning 500 cards at a buylist counter on a Saturday) because it's tuned for our use case, our latency budget, and our catalogue. It's not trying to be a general visual-AI product — it's a purpose-built TCG catalogue matcher.

Why one-engine setups fail at scale

A single recognition engine can demo beautifully and still struggle after staff begin processing the full range of real inventory. The reason is the scan mix.

Demo scans are usually clean, well lit, modern, and English. Real buylist submissions include old sets, alternate printings, played conditions, non-English cards, sleeves, glare, and sideways angles. A trustworthy workflow measures those cases separately and exposes uncertainty instead of relying on one headline accuracy number.

The only reliable solution is different engines for different scan contexts. Buylist counter on a Saturday → in-house engine, tuned for speed and catalogue coverage. Customer submitting high-value singles online → Ximilar, tuned for messy real-world inputs. Graded-card verification → TinEye, tuned for exact-match comparison. Same platform, different engine per task.

The economics of bundling all three

Bundling makes sense at platform level because each engine is used only for the scan context it is designed to handle. Routing also keeps provider-specific integration and error handling out of the merchant workflow.

An individual merchant would otherwise need to procure, integrate, monitor, and reconcile several services with different APIs and failure modes. The important comparison is the total workflow cost and review burden, not an unsupported universal per-scan saving.

So the offer is straightforward: every Storefront Pro merchant gets access to all three engines, routed automatically to the right one per scan context, with no per-engine surcharge on top of the $1,000 USD setup + 2% on TCG item sales. The infrastructure argument from our previous post applies here too — we own or integrate the layer once and amortise it across every merchant.

What this looks like in practice

At a buylist counter, the in-house engine handles the fast path: camera over card, set and rarity identified, condition confirmed by staff, and the item pushed to the buylist submission. Ambiguous results, such as reprinted staples with several plausible printings, surface candidates for staff confirmation.

When staff flags a high-value card ($50+), Ximilar runs a secondary check in the background — validating the visual match and surfacing any condition-grading concerns the staff might have missed. If the match doesn't agree, the card is flagged for manual review. Two-layer protection on the expensive end of the inventory.

When a customer submits a graded PSA 10 for buylist online, TinEye runs an image comparison against the last known reference photo of that specific slab serial number (where we have one). This is authenticity protection — not just 'is this a Charizard' but 'is this the Charizard we think it is, and not a substitution.'

Three engines, three contexts, one merchant workflow. Staff doesn't have to know which engine ran; the platform routes based on what's being scanned and why.

The honest bit

Bundling multiple engines isn't a silver bullet. Recognition accuracy is still bounded by image quality, card condition, and unusual edge cases such as stamped promos, convincing counterfeits, or damage that obscures identifying features. The goal is to route each scan to the most appropriate method and make uncertainty visible.

Ambiguous cases fall back to staff judgement: the platform surfaces candidates and asks. Recognition tooling should augment staff rather than hide the cases where a reliable automated match is not available.

The bigger question

If you're comparing card-shop platforms, the right question about card recognition isn't 'do you have a scanner' — everyone does. The right questions are: which recognition engines do you use, why those and not others, and what's the blended per-scan cost passed through to merchants?

A platform running on one cheap engine and charging a scanning-feature subscription on top is worse economics for the merchant than a platform bundling three engines at its negotiated cost. Same feature on the surface, very different total cost of ownership.

TinEye, Ximilar, and our in-house engine are each excellent at specific problems. Using the right one per job is what turns card recognition from 'demo feature that frustrates staff after two weeks' into 'infrastructure that quietly works.' That's the difference we're trying to ship.