The problem
RealmGX already had the hard part: real trading-card inventory and an established seller workflow. A separate website catalog would create duplicate stock data and another system to keep synchronized.
Back to Work
Case study · TCG e-commerce
RealmGX Shop
A collector-first storefront connected to the inventory system already running the business.
TCG E-CommerceNext.jsStripeFastAPITCGplayer SyncSelf-Hosted
Live storefront
The solution
cranberriestudios split operations from presentation. A dedicated middleware synchronizes and normalizes inventory while Next.js owns discovery, cart state, product presentation, and checkout.
The result
One inventory source now feeds a branded multi-TCG shopping experience with live stock visibility, filtering, seller proof, cart persistence, and Stripe payment handling.
Live inventory
Measurable project facts
Live-site proof captured on October 3, 2026.
1,548
Cards visible at capture
The live storefront reported 1,548 cards across its drop wall when these case-study screenshots were captured.
296
Lifetime reviews
The live storefront surfaces the seller review total directly in the hero proof block.
659+
Total sold
The seller history shown on the live storefront provides purchase-context proof before customers browse inventory.
5
TCG filter lanes
Pokemon, Magic, Dragon Ball Super, Yu-Gi-Oh!, and an Other TCG bucket organize the live inventory wall.
What we implemented
01
Live inventory wall
The storefront merges live middleware inventory with a static fallback, deduplicates listings, and presents the result through grid/table views, game filters, set filters, and sorting.
02
Client-side cart with stock checks
Cart state persists locally while add-to-cart actions validate current stock against the middleware when it is reachable.
03
Embedded Stripe checkout
Checkout can run inside RealmGX with Stripe Embedded Checkout, while the server creates sessions and validates inventory again before payment.
04
Shipping and tax rules
The checkout route calculates economy versus tracked shipping, packaging surcharges, large-order handling, and enables Stripe automatic tax.
05
TCGplayer synchronization service
A separate FastAPI service uses Playwright-driven Seller Portal exports, normalizes inventory into SQLite, and exposes shop-oriented API endpoints to the storefront.
06
Separated storefront and operations
Next.js owns the customer experience; FastAPI, SQLite, synchronization, and seller-session operations remain behind a dedicated middleware boundary.
Implementation
The web app and inventory service are separate deployable concerns. That keeps Playwright, seller-session handling, SQLite, and synchronization logic out of the customer-facing runtime.
Next.js 16
React 19
TypeScript
Tailwind CSS 4
Stripe Checkout
FastAPI
SQLite
Playwright
Docker
What changed for the business
- The customer-facing catalog is driven by operational inventory rather than a second manually maintained product list.
- Customers can move from live card discovery to a persistent cart and secure Stripe checkout without leaving the RealmGX experience.
- Stock is checked again during checkout so the payment path does not rely only on stale browser state.
- Synchronization and seller-portal automation are isolated from the frontend, allowing the store design and inventory machinery to evolve independently.
Have operational data that should drive your store?
We can build the customer-facing layer around the system your business already uses instead of making staff maintain the same catalog twice.