Client context
Bishops Emporium is an antiques and collectables shop in Leominster, Herefordshire. Alongside its own stock it hosts independent dealers, known as cabinet sellers, whose items the shop sells on their behalf and settles with them weekly. Staff take cash and card at the counter, negotiate on price, print swing tags, and post awkward parcels.
The shop wanted to sell the same stock in the shop, on its own website and on the major marketplaces, and to run the whole operation from one place.
Operational challenge
Almost everything the shop sells is a one-off. The same item can be on a shelf, on the webstore and on eBay at the same moment, and two of those channels must not both sell it. Standard ecommerce and point-of-sale products assume repeatable stock with quantities; they do not model unique items, commission sellers with weekly statements, negotiated prices, or a counter that keeps trading when the internet does not.
The requirement was therefore not a website, or a till, or a marketplace integration. It was a single operational system in which every channel reads and reserves stock against the same record, and in which the money owed to each seller is calculated from what actually happened.
Existing fragmentation
The conventional alternative is a set of separate tools: a till, a hosted webstore, marketplace accounts managed by hand, a card terminal, a courier account, and spreadsheets to keep stock, sales and seller statements in line. Each tool holds its own version of the truth and people do the reconciliation. For a shop selling one-off items across several channels, that arrangement produces double-selling, disputed statements and hours of administration every week.
Scope
Opsenium designed, built, deployed and now operates a platform covering:
- Point of sale. A counter till on a wall-mounted screen driven by a Raspberry Pi, with a barcode scanner, receipt printer, label printer and card reader. Staff unlock the till with a personal PIN; the device credential alone cannot perform privileged actions or access financial information.
- Ecommerce. A server-rendered customer webstore at bishopsemporium.com with accounts, baskets, checkout holds, card payment, order tracking and printable order records.
- Inventory. One catalogue with a product lifecycle, category attributes, images and documents, and printed Code128 and QR labels.
- Payments. Card payment through one provider for both the counter reader and the web checkout. SumUp’s ledger is authoritative for card-payment status; the platform remains authoritative for orders, stock and operational state.
- Multi-seller management. Four kinds of seller, each with their own commercial terms and scoped access to their own stock and figures.
- Seller statements and payouts. A weekly Monday-to-Sunday settlement ledger drawn from every channel, branded PDF statements, batch printing at the counter, and payouts whose figures are frozen with their workings.
- Marketplace and listing integrations. eBay transacting in production, Google Shopping publishing the live catalogue, and Etsy integrated and ready for activation, all fed from the same catalogue and stock authority.
- Shipping. Postage bands by parcel size, label purchase through two carriers, and order progression driven by carrier scans.
- Administration. A staff admin portal covering cataloguing, orders, sellers, statements, marketing, analytics, audit, integrations and launch control.
- Support. A support desk built into the admin, and a help assistant on the till and admin grounded in the shop’s own handbook.
- Reporting. Cookieless analytics for the store and telemetry for the platform.
- Cloud infrastructure, monitoring and disaster recovery. Described below.
Solution architecture
The platform is a TypeScript modular monolith: one PostgreSQL database, one versioned API, several thin front-ends and in-process background workers.
- One system of record. PostgreSQL is the only inventory authority. Every surface, including the till, the webstore, the admin and the channel adapters, reads and reserves stock against the same rows. Availability is never stored as a separate number: it is computed live as quantity minus active holds. Row-level locking prevents the till and webstore from claiming the same item concurrently.
- Transactional outbox. External channels that cannot share a database transaction are updated through an outbox: a hold becomes an out-of-stock message, a release becomes in-stock, a sale withdraws the listing, a refund relists. The outbox ensures that intended external updates are durably recorded and retried; reconciliation detects cases where a provider did not accept or apply an update as expected. Marketplace withdrawals, durable retries and scheduled reconciliation minimise the risk of cross-channel overselling and surface exceptions for action.
- Workers. Ten background workers handle the outbox, hold expiry, marketplace reconciliation, payment sweeps, parcel tracking, repricing, the email outbox, unpaid-order cancellation, privacy retention and orphaned-payment recovery.
- Front-ends. A React admin portal, a server-rendered React webstore, a kiosk till interface and a local agent on the till hardware that owns the printers, cash drawer and a disk-backed sale spool.
- Applied AI. Staff photograph an item and receive a draft catalogue entry, constrained to a strict schema, which a person reviews and saves. The draft and the saved version are both retained in the audit history. A help assistant answers from a hand-written corpus and can raise a support case with the user’s consent. Models are not involved in pricing, stock or money.
Delivery approach
Delivery was phased. The core platform, covering the catalogue, the till, the webstore, payments and seller settlements, went live on Azure in July 2026, and a point-in-time database restore was drilled on 24 July, shortly after launch. External channels followed once the core was stable in production: eBay went live on 18 August and Google Shopping on 2 September.
Delivery ran as short increments with working software reviewed throughout. Every change passes an automated test suite against a real PostgreSQL database, including browser end-to-end tests of the store, before a pipeline builds the container image in Azure, applies database migrations and updates the running application. Infrastructure is defined in Bicep and deployed from the repository.
Major capabilities
- Unique-item stock protected by expiring holds rather than counters
- Negotiated prices as an audited override that still pays the seller correctly
- Cash, card, refunds, takings and end-of-day reconciliation at the counter
- Customer accounts with social sign-in, baskets, checkout holds and order tracking
- Weekly seller statements with frozen, reproducible payouts
- Fee-adjusted marketplace pricing and per-parcel-band postage policies
- Marketing campaigns and transactional email through a persistent outbox
- A launch-control checklist that asks the platform, not people’s memory, whether it is ready
- A CCTV event archive for the owners, with lifecycle rules for retention
Integrations
| System | Role |
|---|---|
| SumUp | Card payment for the counter reader and the web checkout, one merchant account |
| eBay | Listings, orders and notifications through the Sell and Inventory APIs |
| Etsy | Listings and order reconciliation |
| Google Shopping | Free listings through the Merchant API |
| Royal Mail Click and Drop | Postage labels |
| Parcel2Go | Postage quotes and labels |
| Microsoft Entra ID | Staff and owner sign-in to the admin portal |
| Google and Facebook | Customer sign-in on the webstore |
| Azure Communication Services | Transactional and support email |
| Azure OpenAI | Product drafting and the help assistant |
| Application Insights | Cookieless store analytics and platform telemetry |
| Backblaze B2 | Independent off-site backups |
| Hikvision CCTV | Event recording and archive |
Security and operational controls
- Identity. Every request resolves to a single principal with a role, a seller scope and a record of how it authenticated. Staff sign in to the admin with Microsoft Entra ID. Customers sign in with an email address and password, or with Google or Facebook. The till authenticates as a device, and a member of staff authenticates on top of it with a PIN; the device credential alone cannot perform privileged actions or access financial information.
- Credentials. Non-recoverable credentials issued by the platform, including passwords, PINs and device tokens, are stored using appropriate one-way hashing. Recoverable provider credentials and integration secrets are encrypted at rest. PIN attempts are rate-limited and logged.
- Roles. Owner and system administrator, staff, and cabinet owner, with seller scope enforced at every relevant call site so no dealer can read another’s figures.
- Secrets. Provider credentials entered by the shop are encrypted at rest with AES-256-GCM. Storage, telemetry and Key Vault are accessed with managed identities, so no account keys exist to leak.
- Audit. An audit trail with before-and-after snapshots covers price overrides, PIN changes, channel go-live, statement rewrites and CCTV viewing.
- Platform hardening. Rate limiting, restricted CORS, security headers, and no API documentation exposed in production.
- Privacy. Cookieless analytics, a scheduled retention worker, and customer-facing legal documents including a GDPR statement.
Hosting and support
The platform runs in Microsoft Azure UK South, in a resource group dedicated to the shop:
- Azure Container Apps for the API and the server-rendered store, with a Static Web App for the admin shell
- Azure Database for PostgreSQL Flexible Server with seven-day point-in-time restore
- Blob Storage for images, labels, receipts and CCTV, accessed with managed identity
- Key Vault for secrets, Application Insights and Log Analytics for telemetry, availability tests and alerts
- Azure AI Foundry for the language model deployment and Communication Services for email
- Container Registry, with images built in Azure by the pipeline
Backups go beyond the platform’s own point-in-time restore. Hourly encrypted database parcels, nightly file copies and nightly verified repository bundles are written to a second provider under a 30-day object lock, so that a compromised source cannot delete its own recovery position. The documented recovery-point objective is one hour, and the restore procedure has been rehearsed and timed.
Support is built into the admin: staff raise cases with a severity and an area, every new case emails Opsenium, and closure emails the shop. Routine cases are worked in a weekly release; urgent faults are fixed as soon as possible under the service level policy.
Outcomes
- The platform is production live and used in the shop’s day-to-day operation.
- The counter till, webstore and eBay transact against one stock authority. Google Shopping publishes the same live catalogue, while Etsy is integrated and ready for activation.
- Independent sellers receive weekly statements produced from the actual sales, and payouts are frozen with their workings.
- The shop has a documented service, backup and business continuity position, with a rehearsed restore.
Opsenium does not publish financial or performance figures for the shop.
Current operating model
Opsenium operates the platform under a managed service agreement that includes hosting, monitoring, backups, support and continuous improvement. The client’s document pack includes the handover agreement, service level policy, GDPR statement, backup and business continuity plan and terms and conditions. The repository, infrastructure definitions and runbook are the client’s.
New capabilities continue to be delivered through the same pipeline and review discipline as the original build.