How Vendr works

Vendr is a command center for solo trading card vendors who sell at conventions, local shows, and pop-ups. It replaces the usual stack of spreadsheets, price-check apps, a cash box, and a pile of sticky notes with one system that tracks a card from the moment it enters your inventory to the moment money changes hands.

The platform is organized around a single loop: bring cards in, price them, put them in binders, sell or trade them on the floor, then reconcile the cash. Every module below is one stage of that loop, and they all read from the same inventory records, so a sale at the table immediately changes what the storefront shows and what your reports say.

One idea runs through all of it: a card carries what it cost you from the day you take it in to the day it sells, so the money side of the business is a by-product of working normally rather than a spreadsheet you maintain on the side.

This page explains what each section does, how it behaves under the hood, and when you would reach for it during a show.

The catalog is your live inventory list. Each row is a physical stack of one card in one condition and language, with a quantity, a cost basis, and an intended sell price.

Adding a card starts with a search against the bundled English, Japanese, One Piece, Magic, and Riftbound card databases. You can search by card name, set, set number, or artist, and card numbers are stored zero-padded (6/015 rather than 6/15) so sorting and scanning stay consistent.

Opening any card shows what it cost you alongside what it is priced at, and, on Pro, the margin at that price. Cards taken in without a recorded cost say so plainly rather than showing a zero, because a card nobody costed and a card that was genuinely free are not the same thing and should not read the same way.

Filters and sorting are shared with Processing and the POS, so the way you narrow a list in one place behaves identically everywhere. Zero-price guardrails flag any item that would otherwise go to the table without a sell price.

Not everything on your table is a printed single. Sealed product, supplies, mystery boxes, memorabilia, store exclusives, and anything else off-catalog is entered as a custom item, with its own title, photo, price, cost, and barcode or generated SKU.

Custom items behave like any other inventory once they exist: they sell at the POS, print labels, file into binders, go out in trades, and appear on the storefront. Card-shaped types can carry a finish; a booster box cannot, because there is no foiling to record.

Creating custom items is a Pro capability. Items entered before a subscription lapses are never deleted or hidden — they keep selling, repricing, printing, and trading exactly as before. The gate is on adding new ones, and nothing else.

Binders mirror the physical binders on your table. Each binder groups inventory so that a customer pointing at page four of your slab binder maps to a real set of records you can find in seconds. Every binder shows a live card count, its retail value, and what those cards cost you to acquire.

Binder view is the page-by-page picture of the real thing: pockets laid out four, nine, twelve, or sixteen to a page, cards dragged between pockets, and blank pages added where you are holding space for cards you have not bought yet. Sleeve colour can be set per binder and tints the cover and the page behind the pockets, so the binder on screen looks like the one in your hand.

A card newly filed into a binder is placed after the last card already in it, not dropped into the first empty pocket. Gaps in a binder are usually deliberate — a sold card, or space being held — and filling them automatically would quietly rearrange an order you set on purpose.

Items move between binders without touching their cost basis or history. Labels and the POS both display the binder a card belongs to, which is what makes a scanned QR code actionable while a line is forming behind the customer.

The free plan includes a binder with a cap on how many cards it holds; Pro removes both limits and unlocks binder view. Grid and list views show every card in a binder on any plan.

Processing is the staging area between acquiring cards and listing them. Cards arrive there from manual entry, bulk imports, buylist purchases, or trades, and stay unlisted until you have checked and priced them.

The queue is a draft, and moving a card to the catalog is the moment it becomes real. That is deliberate: a card often arrives with a provisional cost, or none at all, and gets corrected here. Nothing is committed to your books until it leaves the queue, so the figures that reach your reports are the ones you settled on rather than the ones you typed first.

Bulk import accepts a spreadsheet, sanitizes it, and runs an exception-based review: rows that match cleanly are accepted, and only the ambiguous ones require your attention in an inspection sheet. A blank cost column stays blank rather than being recorded as free.

You can move a whole lot to the catalog at once, or send part of it now and leave the rest in the queue — useful when you are ready to list three of a playset and still deciding on the other two. Either way the move runs as one atomic operation, so quantities cannot drift or double-count if something fails midway.

The queue shows how much is waiting, both as lots to work through and as cards those lots represent, and can be filtered down to the ones missing a sell price — the single thing that will stop a card being moved to the catalog.

Every card carries a cost basis: what you paid for it. It is set when the card is taken in, corrected in the processing queue if you got it wrong, and blended as a weighted average when more copies of a card you already own arrive at a different price. Buying the same card twice at different prices leaves you with one honest average rather than whichever figure happened to be typed last.

When a card sells, its cost is written into the sale itself rather than looked up afterwards. This matters more than it sounds: a card that sells out is removed from inventory, so a cost read at reporting time would be gone for exactly the cards that sold best. Recording it at the moment of sale also means repricing a card later cannot rewrite what a past sale earned.

That gives every sale a cost, a profit, and a margin, per card and per transaction. Cost of goods and gross profit appear in the reporting summary and in exports, alongside — not mixed into — the cash-flow figures, because money spent on stock and money made on a sale answer different questions.

Cost is shown to every plan: it is your own number, and you typed it. The margins and profit figures derived from it are Pro. Where a card has no recorded cost, screens say so and count the missing rows, rather than presenting a partial total as a complete one.

Inventory spend can optionally be posted to the cash ledger as an expense when cards move from the queue to the catalog. It is off by default, because whether buying stock belongs in your cash flow is a bookkeeping choice rather than a fact about the card.

Every inventory record can carry a printed tag. The default is a 1.5in square QR label sized to sit inside a standard card sleeve without overhanging the 2.5in by 3.5in card boundary.

The QR payload is deliberately minimal: it contains only a short SKU. That keeps the modules large and readable under bad convention lighting and lets the scanner resolve the full record from your own data rather than from the code itself. The code and the short code always print; everything else is your choice.

You pick which details appear — price, card name, set and number, condition, printing or finish, binder or bin, store name — and the layout adapts as you add them, shrinking type and tightening spacing rather than letting text run off the sticker. Price prints first because it is the thing a customer reads from across the table. Labels can be laid out with the code above the text or beside it, rotated on the media, and printed with or without cents.

You can print several copies of a card in one run; copies come off the printer together rather than scattered through the batch. A card whose last copy sells leaves your inventory, and with it the label queue, so you are never printing a tag for something that left the table an hour ago.

Two output formats are supported: Avery label sheets on a normal office printer, and continuous thermal rolls in square, rectangular, circular, or mini-pocket shapes. Layouts are generated with physical units and exact page sizing, so what prints matches what the preview showed, across multiple pages.

The POS is built for a single operator working a table. It accepts input from a USB barcode scanner or the device camera, and prioritizes QR codes so your own labels resolve fastest. Camera scanning is a Pro capability; typing or scanning a code with a hardware scanner is not.

The camera stays on between scans rather than cycling off, with a 1.5 second duplicate suppression window so a card lingering in frame is not added twice. Each successful scan gives audio and visual confirmation, which matters when you cannot look at the screen.

Cart quantities are checked against real stock in real time: a line cannot exceed what you actually have. Checkout runs as one atomic transaction that records the sale and decrements inventory together, so a dropped connection cannot leave you having sold a card that is still listed. A card whose last copy sells leaves your inventory and its binder in the same operation.

An available-inventory pane sits alongside the cart for the times a customer knows what they want but the card has no label on it yet.

Photo scanning identifies a card from a picture. You point the camera at a card you are holding, Vendr reads it, and you get the matched card, its market price, and a suggested offer — without typing a name, a set code, or a number.

It exists for one situation: somebody has put a stack of cards on your table and is waiting. Searching for a card by name is fine at home and slow in front of a customer, particularly for a set you do not know well or a card whose name is printed in a language you do not read.

A scan opens with the card it matched. The picture, the name, the set and number, and the rarity are all read from the photo, and the market price is fetched for that exact printing. If the photo could reasonably be more than one card, the alternatives are one tap away rather than hidden — a misread that silently prices the wrong printing is the failure worth protecting against.

Underneath is your offer. It starts at your default buy percentage from Settings, applied to the market price, so the common case needs no interaction at all. The amount and the percentage are two views of one number: type either and the other follows.

The four buttons move the offer in whole percentage points of market. On a card at 70%, +10% takes you to 80%, not to a price ten percent higher — the step is the same size wherever you start, which is what makes it usable without doing arithmetic while somebody watches. On a bulk-priced card there is no market percentage to move, and the buttons say so by being unavailable rather than quietly changing the cash.

Scanning costs a scan token. One token per photo, including a photo that comes back unreadable — the work of reading the image happens either way, and a scan that fails still costs Vendr what a scan that succeeds does. Everything else in the app is unmetered; this is the only part with a count against it.

Pro includes a monthly allowance of tokens, granted automatically and expiring at the end of its period. Free tokens are always spent before anything you have bought, so a purchase you make today is not the balance that runs out next. Your balance and what it is made of are on the Subscription page.

If you run out, tokens can be bought in packs — by card, which credits them within seconds, or by bank transfer in pesos where that is offered, which is approved by hand. Buying scans is not a subscription and does not change your plan. Bought tokens last a year.

Nothing about scanning is required. Every card it can find, search can find too, and a store that never opens the camera is never charged a token. It is a speed tool for the minutes when speed is what you are short of.

Convention Wi-Fi fails. Partitioned offline mode caches your catalog locally in the browser so scanning, lookups, and cart building keep working with no connection.

Sales made while offline are queued and synced automatically once the network returns, replayed oldest first and stopping at the first failure so nothing is posted twice. A cache status indicator shows what is stored, when it was last refreshed, and how many transactions are waiting, plus a manual sync button for when you want to force the issue before packing up.

A card that is not in the cache can still be sold, with a warning, so an unrecognised scan never becomes a reason to turn away a paying customer. Those lines are flagged and reconciled when the connection returns.

The trade desk handles bi-directional deals: cards leaving your inventory and cards coming in from the customer, valued against each other in one settlement.

You build both sides of the offer on screen, the running difference updates as cards are added, and settlement applies everything at once. Cards received are routed into Processing rather than straight to retail, so you decide their price and disposition later rather than under pressure at the table. Notes captured during the trade carry through to the cash ledger.

Cards leaving your side are treated exactly like a sale for reporting: their cost travels with them, so a trade shows the same margin arithmetic a counter sale would.

Buy Cards is straight buylist intake: a customer sells you cards for cash. You build the purchase line by line, with photo and OCR assisted entry for large stacks.

Purchases apply weighted average cost, so buying more copies of a card you already own blends the cost basis correctly instead of overwriting it. Your margin reporting stays accurate no matter how many times the same card passes through.

Purchased cards land in Processing at the price you paid, ready to be priced for sale before they reach the table.

Every store gets a public page at its own slug, generated automatically from the store name. Customers browse your listed inventory from their own phone while standing at your table, in a grid, a list, or — for Pro stores — a binder view that shows a chosen binder page by page the way it sits on the table.

Shoppers filter by game, condition, and binder from a single filters panel, sort six ways, and search by name. The chosen view is remembered per binder, so the arrangement that suits your slab binder does not follow them into your bulk box.

The customer cart is session-only by design: nothing persists across visits, and no customer account is required. When they are ready, the Fast-Track QR hands their whole cart to your POS in a single scan, which works even when their phone and your tablet are both fighting the venue network.

Only your prices, stock, and card details are ever sent to a shopper's browser. What plan you are on, what you paid, and every other private column stay on the server.

Every sale, purchase, and trade writes to one ledger. Reporting is the view over that ledger, filtered by date range so you can look at a single show day or a whole season.

The summary covers both halves of the business: sales revenue, cost of goods, and gross profit on one side; gross inflows, payouts, liquid cash, and outstanding store credit on the other. Bank and e-wallet takings are broken out per account so a day's figures can be reconciled against what actually landed where.

A transaction drawer opens the full detail behind any entry, including per-card cost and profit and the notes captured during buys and trades. Any view exports to Excel with the same figures, itemised per card, for bookkeeping.

The dashboard is the daily snapshot, on every plan: items in catalog, number of binders, total inventory value, and current plan.

Inventory health breaks your stock into aging buckets at 30, 60, and 90 days, which is how you spot the cards quietly occupying binder space without moving. Advanced analytics — revenue against spend over time, so you can see whether a show actually cleared what it cost you to attend — is the Pro part of this screen.

Settings is one hub covering store details and branding, POS behavior, hardware defaults for label printing and scanning, trade and inventory rules, and account security.

Payment methods are chosen per store: cash, card, trade credit, digital, and named bank or e-wallet accounts that each get their own line in reporting. Sales tax can be collected at checkout or left off for tax-inclusive pricing, and receipts carry a message you set.

Currency is set globally and formatting flows through every surface: labels, POS totals, storefront prices, and exported reports all follow the same setting rather than being configured separately.

The Free tier covers the catalog, the processing queue, a binder, the public storefront, and selling at the POS with a hardware scanner or typed codes. It is a working setup for a small table, not a demo.

Pro adds camera scanning, label printing, the trade desk, buy-list intake, reporting and margin figures, advanced analytics, binder view on both your binders and your storefront, sealed and custom items, and unlimited binders and binder capacity.

Pro includes a 7-day free trial that activates instantly with no credit card required. Billing can be monthly or annual, and the pricing card shows the monthly-equivalent cost so the comparison is honest. You can switch cycles from the billing pane in Settings.

If a subscription lapses, nothing you created is deleted. Custom items keep selling, binders keep their cards, and your history stays intact — the Pro surfaces stop being available, and everything already in the system goes on working.

Each vendor gets a unique referral code. A new vendor who signs up with your code receives a longer trial: 10 days instead of the standard 7.

When someone you referred converts to a paid subscription, 7 days are added to your own subscription. The referrals page tracks your code, redemptions, and rewards earned.