Operating marketplace seller software as a state machine, not a status label

Marketplace seller software operations need a controlled record of who changed what, which state followed and how the seller can correct or reverse it. This guide uses one fictional merchant established in England, its authorised seller entity, one named marketplace account and one bounded job. Approved product and stock records leave the seller's source system; later order events return.

No live marketplace, supplier, product, payment or customer record was accessed. Research closed on 6 September 2026. The workflow below is an editorial operating recommendation, not proof of marketplace permission, legal compliance or service performance.

What to take away

Model each seller operation as a state machine with entry evidence, owner, test, timestamp and permitted next state.
Do not collapse placed, accepted, authorised, captured, confirmed, fulfilled, retained and settled into a single sold label.
Keep catalogue, stock, price, orders, payment, fulfilment, returns, refunds, disputes, settlement, tax and support as separate functions.
Reconcile marketplace responses against the seller's own ledger, not a shared dashboard total.
Route safety complaints, data concerns and account compromise to separate owners without rewriting original records.
Tie every record move to one batch ID, carrying its evidence, owner and permitted next state.
Hold the whole batch when a safety, consumer, privacy or security gate fails, and give each exception one owner.

Fix the actors and the record boundary

The legal seller owns the decision to offer the product. The marketplace operator controls its account and interface. A software supplier may transmit or transform records, while a managed provider may operate part of the process. Payment, fulfilment and customer-service parties can differ again. Record the real contract and activity rather than assigning responsibility from a job title.

Name the seller entity, authorised account, product population, source system, interface version, operating timezone and responsible owner. Keep catalogue content, stock, price, advertising, orders, payment, fulfilment, cancellation, return, refund, dispute, settlement, tax and customer support as separate functions. A shared dashboard does not merge them.

HMRC's digital-platform seller guidance distinguishes sellers from platform operators and says platform reporting does not replace ordinary business and tax records. Reconciliation therefore begins with the seller's evidence, not a screen total.

Set up the work item

Open one work item for each seller, marketplace account and product population. Record the source version, interface and batch ID. Amazon Seller Central, eBay Seller Hub and feed tools such as Linnworks work this way.

The blank marketplace software budget helps size VAT review and exit cost before other spending. Assign catalogue and safety owners, then add consumer, privacy and security owners. Every decision needs a recorded sign-off.

Use a state machine, not a status label

Every transition needs an entry record, owner, acceptance test, timestamp, version and permitted next state. The exact names can differ by account or contract, so maintain a translation table.

Use a state machine

State	Entry evidence	Owner decision	Exit or exception
Product proposed	source record, rights and claim evidence	accept, return for correction or reject	approved product version
Listing submitted	approved payload and account authority	acknowledge or queue rejection	published, suppressed or withdrawn
Stock offered	source quantity, reservation rule and event time	accept or quarantine conflict	current, corrected or stopped
Order placed	marketplace event and customer-facing terms version	validate identity and completeness	accepted or declined
Payment authorised	processor event mapped to order	permit later capture under reviewed rule	expired, failed or captured
Fulfilment released	accepted order and stock reservation	dispatch or hold exception	fulfilled, cancelled or returned
Refund or dispute	authorised remedy or payment case	reconcile amount and reason	completed, challenged or unresolved
Settlement recorded	remittance and accounting evidence	reconcile differences	closed or exception queue

Do not collapse placed, accepted, authorised, captured, confirmed, fulfilled, retained and settled into "sold". Cancellation, return, partial or full refund and dispute may reopen earlier records without erasing the history.

Admit product and offer data carefully

Before submission, the catalogue owner verifies identifiers, description, claims, images and usage rights. The product-safety owner records the seller's supply-chain role, traceability, warnings, instructions, applicable regime and expiry. OPSS product-safety guidance separates Great Britain and Northern Ireland treatment and notes that product-specific rules can take priority.

For an unsafe or non-compliant product, the normal publishing flow must stop. OPSS maintains current business notification guidance for relevant authorities. A qualified specialist must decide what the actual product and territory require. Software withdrawal is only one part of a corrective action.

The consumer owner checks the rendered description, seller identity, total price, delivery, payment route, ordering steps, correction and confirmation. GOV.UK's online-selling guidance identifies these subjects. CMA material last updated on 7 January 2026 addresses the presentation of mandatory fees, taxes and charges. These are qualified-review inputs, not a universal page approval.

Optional extras need a distinct state. Current government additional-charge guidance says the customer must actively choose an additional payment. Record the default, choice, displayed amount, confirmation and later correction. A platform switch does not prove that the rendered journey is acceptable. Keep the opt-in wording in the test fixture.

Mark each field accepted, rejected or unresolved

Compare the proposed payload with the signed source record. Mark each field at accepted, rejected or unresolved.

Mark each field

Field	Evidence held	Permitted states
SKU or GTIN	Supplier record and image licence	accepted, rejected, unresolved
Title and claims	Signed copy sheet	accepted or rejected
Price and delivery	Dated source price file	accepted after sign-off
Stock quantity	Timestamped warehouse file	accepted or quarantined

Publish through bounded batches

The release controller creates a versioned batch from approved products only. A preflight compares the outgoing payload with the seller record, checks account authority and confirms that production credentials are unavailable to the test environment. Synthetic identifiers test transformations, rejected updates, duplicates and late events.

After submission, capture acknowledgement per record. Do not treat transport success as publication. Sample the rendered listing against the approved version, then reconcile the marketplace response to the seller's ledger. Unknown, rejected or partially applied records enter an exception queue with evidence and an owner.

They must not be silently retried until the failure class and idempotency rule are known.

Stock changes need the same discipline. State the source of truth, reservation point, update timestamp and conflict rule. If stock evidence is stale or contradictory, pause affected offers under a buyer-set threshold. No universal delay or overselling tolerance is claimed here.

After release, log the outgoing hash, send time, interface response and resulting marketplace state.

A seller might set a stock refresh every 15 minutes and a daily reconciliation window. Those figures are an example the buyer sets, not a published standard.

Example: a batch with one rejection and one quarantined file

Identifiers here are fictional. Batch 4317-09 holds four product records and one stock file.

Example: a batch

Record 3 fails the claim check because the supplier image licence is absent. The record stays rejected and does not enter the payload.
A stock file arrives at 09:12 with a quantity that conflicts with the warehouse sheet. The file is quarantined and passed to the operations owner.
The remaining three records publish. The last accepted quantity keeps selling until the stock item clears.

The batch closes only when record 3 and the stock file are resolved or queued.

Process orders without losing later events

An inbound order passes schema, account, identity and duplicate checks before acceptance. The workflow then maps payment authorisation, capture and settlement separately. Fulfilment release requires the approved product, available stock, reviewed delivery promise and valid order state.

Customer remedies remain operational states. GOV.UK's returns and refunds page explains that online sales can carry cancellation and refund rights with exceptions. Consumer counsel must determine the route for the actual goods and facts. The system should preserve notice, receipt, return, inspection, decision, payment reversal and communication evidence without overwriting the original order.

Customer service can request correction, but it should not rewrite product facts, payment or tax records without the named owner. Route safety complaints to the product-safety owner, data concerns to the privacy owner and suspected account compromise to security. One ticket may open several independent investigations.

Keep privacy and security controls operational

Map each personal-data purpose, source, recipient, access role, retention rule and deletion route. The ICO's controller and processor guidance makes the factual role analysis explicit. Do not assume that the marketplace or supplier is the controller for every operation.

Cookies, pixels, SDKs and similar storage or access technologies have a separate PECR decision. The current ICO record dates final storage and access guidance to 29 April 2026. A rejected consent state must not be converted into approval by a retry or server-side route.

Limit privileges by task, log administrative actions and remove access when responsibility ends. NCSC's secure SaaS guidance addresses customer configuration, monitoring, protected copies and recovery. Its secure online service guidance separates logging, security monitoring, transaction monitoring and incident management. Neither source certifies the proposed system.

Test accessible completion and recovery

Accessibility review covers both the customer journey and staff exception work. Test product information, price, choice, authentication, error recovery, order confirmation, cancellation, refund and support with the agreed methods. The government service-provider guide explains the Great Britain Equality Act context. It is not an automatic verdict on a marketplace or tool.

Prepare rollback before release. Preserve the last accepted product version, open-order ledger, access list and seller-owned export. A rollback decision states which writes stop, which customer obligations continue and how later events are reconciled. Rehearse an isolated restore using fictional records; downloading a file is not evidence that it can be used.

When a security or personal-data incident occurs, contain access without destroying evidence, preserve the timeline and call the named specialist. The ICO breach reporting page is visibly under review following the Data (Use and Access) Act and requires publication-day checking. The NCSC incident-management collection links preparation, response, recovery and continuity.

Reconcile tax and advertising separately

The finance owner matches orders, captures, refunds, disputes and settlements to accounting records. HMRC's VAT record guidance lists supplies, adjustments and supporting records. It does not determine a transaction's VAT treatment; the named adviser must do that.

Invoices and credit notes feed the ledger, so pick software from the government list of MTD for VAT compatible software. That keeps VAT records aligned with the order states in the seller tool.

Paid placement, marketplace advertising and endorsements need an advertising owner even when catalogue staff publish them. CAP Code recognition rules require marketing communications to be identifiable. Keep the commercial brief, approved claim, targeting instruction and rendered disclosure in the evidence packet.

Operate exception, correction and exit queues

Each queue entry records the affected entity, state, timestamp, evidence, severity, owner and next action. Product mismatch, unsafe item, price error, stock conflict, duplicate order, payment discrepancy, refund delay, privacy request, accessibility barrier and account-security event do not share one resolution path.

Correction should create a new version and preserve the prior one. A material product or price problem can require withdrawal while open orders and customer contact continue. An incident record identifies containment, specialist notification, recovery evidence and the decision to resume. Do not erase the facts to make a dashboard green.

Close a batch only when every product and order event sits at accepted, rejected or queued.

Exit is an operating state, not a contract footnote. NCSC supplier-assurance questions include data return, secure deletion, service transfer and changing risk. Test export, isolated restore, access removal, open-order handover and return to the current process before dependence grows.

Set evidence-led review points

Daily, weekly or monthly labels are not universal standards. The merchant sets cadence from event criticality, volume, contractual duties and operational capacity. Every review states population, clock, exclusions, source query, owner and buyer-defined threshold.

Recheck after a supplier edition, marketplace interface, product regime, data flow, payment route, tax view, advertising practice or accessibility method changes. The decision is pass, rework, hold or stop for the exact version. Treat the consumer, safety, tax, privacy, security, accessibility and exit gates as non-compensating; commercial benefit cannot override a failure.

The next practical step is to run the state machine with one shared fictional fixture. Production stays disabled until every transition has entry evidence, an owner, an acceptance rule, an exception route and a demonstrated rollback.

Before you act

Name the seller entity, authorised account, source system and responsible owner.
Define each state with entry evidence, owner decision and permitted next state.
Verify product identifiers, claims, images and usage rights before submission.
Create versioned batches from approved products only and capture acknowledgement per record.
Map each personal-data purpose, source, recipient, access role and retention rule.
Test accessible completion and recovery for customers and staff.
Record the batch ID, source version, interface and owner.
Mark every proposed field accepted, rejected or unresolved.
Log the outgoing hash, send time and interface response.
Timestamp a quarantined stock item and give it an owner.
Reconcile order, payment and refund events to the ledger.

Common questions

Why should a marketplace seller use a state machine instead of a status label?

A status label hides the sequence of who changed what and which state followed. A state machine records entry evidence, owner, acceptance test, timestamp, version and permitted next state. This lets the seller correct or reverse actions and prevents collapsing distinct events like placed, accepted, authorised, captured, confirmed, fulfilled, retained and settled into one sold label.

How should stock changes be handled when evidence is stale or contradictory?

State the source of truth, reservation point, update timestamp and conflict rule. If stock evidence is stale or contradictory, pause affected offers under a buyer-set threshold. No universal delay or overselling tolerance is claimed. Stock changes need the same discipline as other transitions, with unknown or rejected records entering an exception queue.

What privacy and security controls must remain operational?

Map each personal-data purpose, source, recipient, access role, retention rule and deletion route. Do not assume the marketplace or supplier is the controller for every operation. Cookies and similar technologies need a separate PECR decision. Limit privileges by task, log administrative actions and remove access when responsibility ends. A rejected consent state must not be converted into approval.

What must be true before a product record can move?

The record needs written evidence, a named owner and a permitted next state. Any open consumer or safety item blocks the move. A named person signs it off.