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

The pattern we see consistently: a platform ships with one recognition engine, it demos beautifully, staff get trained, real intake begins. Week one, accuracy is 92%. Week four, it's 74%. Why?

Because the scan mix shifts. Demo scans are optimistic (NM, good light, common sets, English). Real buylist submissions are the long tail — old sets, alternate printings, played conditions, occasional Japanese cards, sleeves, sideways angles. The engine that was 92% on the demo mix is 74% on the real mix. And that 18-point accuracy gap is the difference between 'staff trust the tool' and 'staff stop using the tool and go back to typing.'

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 for us (the platform) because we're aggregating demand across hundreds of merchants and negotiating volume pricing with the providers. The blended per-scan cost across three engines, used correctly, is lower than any single engine used exclusively — because you're only using each engine for the scans it's cheapest at.

It doesn't make sense for an individual merchant to procure and integrate three engines themselves. The per-scan prices at individual-account volumes are 5-10x higher than what a consolidated platform pays. The integration engineering is non-trivial. Error-handling across three APIs with different failure modes is its own project.

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 setup + 2% on 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, staff scans 400 cards in an hour. The in-house engine handles the fast path — camera over card, set and rarity identified, condition tapped by staff, pushed to buylist submission. Matches happen in under 200ms. Ambiguous results (multiple plausible printings, which happens on reprinted staples) surface two or three candidates; staff picks one with a tap.

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 the base rates of weird edge cases (Japanese promos with hand-drawn stamps, counterfeit prints so good they fool humans, cards that were damaged in ways that partially obscure identifying features). The goal of the three-engine approach isn't 100% accuracy — it's moving from 'the one engine we bought works for 74% of real scans' to 'the right engine per scan works for 94%.'

The remaining 6% is handled by fallback to staff judgement — the platform surfaces candidates and asks. That's the right design. Recognition tooling should augment staff, not replace them on the 5% of cases where algorithms still can't win.

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.