A Practical Card-Show Vendor Tech Stack

Map the workflow before choosing software

Start with one real interaction. A collector finds a card, pays or asks about similar inventory, scans a QR offer, receives the promised item, returns to a product page, and later buys. The stack has to preserve the item, quantity, seller, customer, consent, event source, payment, and follow-up state across those steps.

Every manual export, duplicate entry, and disconnected account creates a failure point. The goal is not to buy the most apps. It is to create the smallest reliable system that works when one person is answering a question, another is paying, and a third wants the next drop.

Draw the workflow with the authoritative system for each state and the integration that moves it. Then test the failure path, not only the ideal demonstration.

Layer 1: inventory and product data

The inventory source of truth needs a stable product identity, seller ownership, quantity, condition, price, cost basis, variants, images, and availability. For high-value collectibles, it may also need grading company, certification, serial, and item-specific photographs.

Decide how show sales, cash transactions, bundles, trades, holds, refunds, and online orders change inventory. Prevent the same item from selling in two channels. Use an explicit review state for products whose quantity or condition is uncertain after the event.

Test export and recovery. A visually attractive catalog that cannot produce a useful inventory record is an operational trap. Use the unsold inventory guide for the closeout workflow.

Layer 2: in-person payments

The payment system should support the seller's transaction volume, devices, receipts, refunds, taxes, reconciliation, and staff permissions. Understand who is the merchant, how funds settle, what fees apply, and where disputes are handled.

Stripe Terminal documents an in-person payment architecture built around compatible readers, applications, and server integration. Stripe also documents supported offline collection configurations and warns that offline payments carry risk because authorization occurs after connectivity returns. Follow the exact provider and integration guidance. Do not assume every reader or custom checkout can operate offline.

Test temporary connectivity loss, a declined payment, retry, cancellation, refund, and duplicate submission. Never collect raw card details on paper as a fallback.

Layer 3: QR capture and consent

Use an event-specific seller-branded destination, not a generic link that loses source. The page should load quickly on cellular service, explain the benefit, ask for minimal information, and separate resource delivery from optional marketing.

The capture endpoint should validate the resource identifier, normalize and deduplicate email, rate-limit abuse, record first-touch attribution, and return a generic response. The confirmation should deliver the requested item immediately.

Use the email collection playbook to design the full physical and digital funnel.

Layer 4: seller-owned CRM

The CRM should connect source event, interests, consent, conversations, accounts, orders, membership, and suppression to one customer profile within one seller. It needs an audit trail for important state and an export process appropriate to the seller's ownership and platform terms.

In a multi-seller platform, tenant isolation must be enforced for every query and action. A seller identifier sent by the browser is not proof of access. Test that one seller cannot see, export, segment, or message another seller's customer.

The card-show vendor CRM guide includes the minimum record, useful segments, and eight evaluation scenarios.

Layer 5: email delivery and follow-up

Transactional and marketing email have different purposes. Resource delivery, receipts, and service messages should not depend on marketing consent. Recurring nurture should require the appropriate consent and recheck unsubscribe, complaint, bounce, and suppression state before every send.

Use a provider with authenticated sending, delivery events, suppression handling, and a documented test method. Queue sends through a durable outbox or equivalent so temporary failures retry without duplicating successful messages. Route replies to a monitored inbox.

The follow-up email sequence gives a five-message structure, while the timing guide explains how intent changes the schedule.

Layer 6: owned storefront and checkout

The storefront is the durable destination for the booth relationship. It needs seller branding, product and collection pages, accurate inventory, mobile checkout, customer accounts, source attribution, fulfillment, refunds, shipping, and clear policies.

Use one canonical seller origin, stable descriptive URLs, unique metadata, and accurate product structured data. Keep private account and checkout routes out of public sitemaps. Unpublished stores and archived products should not look available to people or search systems.

Read the owned storefront guide for the commerce, SEO, data ownership, and evaluation checklist.

Layer 7: wallet loyalty and membership

Add loyalty after customer identity, orders, refunds, and balance state are reliable. The program needs published earning, redemption, expiration, and return rules plus an authoritative ledger.

Google Wallet documents loyalty classes for shared program properties and loyalty objects for individual users. Apple documents the creation, signing, distribution, and updating of Wallet passes. In both cases, the pass is a convenient surface. The seller's system remains the authoritative record for membership and balance.

Use the wallet loyalty guide to plan secure identifiers, updates, offline behavior, and measurement.

Layer 8: attribution and reporting

Preserve the first-touch show source through resource request, signup, account, purchase, and repeat behavior. Keep campaign touch data separately. Browser analytics helps explain behavior, but server-side order and customer state should determine paid and published outcomes.

Report event-day revenue and profit separately from attributed post-show contribution. Track qualified contacts, opt-ins, accounts, first buyers, repeat buyers, refunds, and contribution margin. Do not treat scans, opens, or contacts as revenue.

Use the profit calculator and capture calculator as the planning and review pair.

Define every provider boundary

Write down what happens when a provider is slow, unavailable, or retries a webhook. Critical operations should be idempotent. Provider payloads should be validated and translated into internal states rather than leaking through every layer.

For each integration, document:

authoritative system and identifiers;
authentication and secret ownership;
timeouts and retry policy;
idempotency key or duplicate protection;
webhook verification;
failure and reconciliation queue;
data retained and redacted from logs;
support escalation; and
safe disable or replacement path.

This is especially important for payments, email, shipping, wallet signing, DNS, and customer identity.

Build for poor connectivity

Test on cellular service, a throttled connection, and temporary disconnection. Decide which operations must stop, which can queue, and which have a provider-supported offline mode. Show clear pending or failed states so staff do not retry blindly.

Print a readable backup URL below every QR code. Keep a secure paper operating sheet for counts and incident notes without recording card details or exposing customer information. Charge devices and carry tested power, but do not let hardware backup replace state reconciliation.

Evaluate tools with failure scenarios

Ask every proposed stack to demonstrate:

duplicate resource submission;
explicit opt-in and no opt-in;
unsubscribe after nurture is scheduled;
payment request retried after a timeout;
temporary email provider failure;
same product attempted in two channels;
partial refund and loyalty reversal;
archived product and unpublished store behavior;
export of seller-owned inventory and customer data; and
cross-seller access denial.

Compare total cost using real product count, contacts, email volume, payment volume, staff seats, domains, and add-ons. Include the time required to reconcile tools and repair failures.

Frequently asked questions

Can one platform handle the whole vendor stack?

It can orchestrate the workflow while still using specialized providers for payments, email, shipping, and wallet distribution. Provider boundaries and failure behavior should remain visible and testable.

What should I implement first?

Start with accurate inventory, payment, and order state. Then connect consented capture, CRM, follow-up, and an owned storefront. Add loyalty after the underlying customer and transaction state is reliable.

Do I need offline payments?

Only when the payment provider and exact integration support them and the seller accepts the documented risk. A hotspot is useful but does not replace a failure plan.

How do I avoid getting locked into a vendor?

Test useful exports, document identifiers and provider boundaries, use standard domains and formats where possible, and understand data access and termination terms before launch.