Retail operations
The buy counter is where a card shop makes or loses its margin
Price trade-ins and manage shop inventory with dealer bid data, per-printing identity and fast lookup by scan or search.
The problem
Where this project usually goes wrong
Every card that crosses a buy counter is a pricing decision made in front of an impatient customer. Get it wrong generously and you have paid too much for stock you now have to shift; get it wrong meanly and the customer takes their collection to the shop down the road and tells people why.
Most counters run on a percentage of retail applied from memory or a binder. That rule is wrong almost everywhere, because the share a card is really worth to a dealer swings from roughly a seventh of retail on bulk to over half on scarce singles. One rule cannot cover both ends of a box.
And the throughput problem is real. A customer arriving with a shoebox is fifteen minutes of staff time if every card is a manual search, which is why so much bulk gets bought blind at a flat rate that quietly loses money on the good cards.
What it needs
The fields that decide it
- listType: buylist
- The dealer bid for the exact printing in front of you, rather than a percentage rule that is wrong at both ends of the box.
- Per-printing identity
- Set, number and finish decide the value. A shop that pays bulk rates for the wrong printing is losing the only cards worth buying.
- Card recognition
- Identify a card from a photo or a live camera in milliseconds, so a shoebox is minutes of work rather than an afternoon.
- Both markets priced
- European shops price against the market their customers sell into, not a converted American figure.
- Bulk export
- A local copy means the counter keeps working when the internet at the venue does not.
In practice
The two queries that matter most
Written for brick-and-mortar shops, buy counters and events. Both work the same way for every game we carry.
Quote a trade-in from the card in hand
curl -G "https://api.tcggraph.com/v1/cards" \
-d game=magic-the-gathering \
-d "name=Ragavan, Nimble Pilferer" \
-d listType=buylist \
-H "Authorization: Bearer $TCGGRAPH_KEY"Every printing comes back with its own bid, so the staff member picks the one in front of them rather than averaging across a decade of reprints.
Identify a card from a photo, then price it
{
"match": {
"id": "mtg_f6555d1f-d4c",
"name": "Ragavan, Nimble Pilferer",
"set": "Modern Horizons 2",
"collectorNumber": "138",
"finish": "foil",
"confidence": 0.991
},
"prices": [
{ "listType": "retail", "currency": "USD", "market": 61.40 },
{ "listType": "buylist", "currency": "USD", "market": 34.00 }
]
}Recognition returns the exact printing, not just the card name, which is the only version of the answer a buy counter can act on.
Avoid these
Three mistakes that are expensive to undo
Each of these is cheap to get right at the start and painful to retrofit once you have user data shaped the wrong way.
One percentage for the whole box
The correct share of retail is roughly a seventh on sub-dollar cards and over half on premium singles. A single rate overpays on bulk and underpays on the cards that actually matter.
Pricing by card name
The name is the least valuable part of the identity at a buy counter. Set, collector number and finish are what separates a fifty-cent card from a fifty-dollar one.
Assuming connectivity at events
Convention wifi is not a dependency you want between a customer and a quote. Hold a local copy and sync when you can.
Questions
Card shop and buy desk, answered
Also built on this
Other projects, same catalogue
Ship your card app this weekend
$19 a month for 25,000 credits, no sales call and no contract. Pick a plan and your first query runs in under a minute.