Running a marketplace workflow through approved product, stock and order states

A marketplace seller software operating workflow should move a record only when its evidence, owner and permitted next state are known. This process covers one fictional England merchant, its authorised marketplace account, approved product and stock data, and later order events. Production remains disabled.

Research closed on 6 September 2026. The steps are buyer-owned operating recommendations, not observed performance or legal approval.

Open a controlled work item

Create one identifier for the seller, account, product population, source version, marketplace interface and planned batch. Assign catalogue, safety, consumer, account, privacy, security, accessibility, finance and operations owners. A person may hold several roles, but each decision needs a recorded sign-off.

The product file contains identifiers, description, claims, media rights, traceability, warnings and expiry. OPSS product-safety advice identifies supply-chain responsibilities and separates Great Britain from Northern Ireland. The specialist applies the correct product regime; the tool does not decide it.

Approve product, price and choice

Compare the proposed payload with the seller's signed source record. Mark each field accepted, rejected or unresolved. The consumer owner then inspects seller identity, description, total price, delivery, payment, correction and confirmation against current online-selling guidance.

Optional charges have a separate approval. The government additional-charge guidance requires an active customer choice. Preserve the default, rendered wording and selected state in the fixture. An unresolved consumer or safety item stops submission.

Submit and reconcile the batch

Use fictional identifiers to test transformations, rejected records, duplicates and late acknowledgements. Release only approved items. Record the outgoing hash, send time, interface response and resulting marketplace state. Transport success is not publication; sample the rendered result against the authorised version.

Stock updates record source quantity, reservation rule and event time. Contradictory evidence enters quarantine. The buyer sets any freshness threshold, because this article provides no universal service level.

Keep order and money states apart

Map order placed, seller acceptance, payment authorisation, capture, fulfilment, cancellation, return, refund, dispute and settlement separately. A retry must not create another order or payment. Reconcile each event to seller, marketplace, payment and accounting records before closure.

HMRC's VAT-record guidance covers supplies, adjustments and supporting records. A tax adviser decides the actual treatment. Customer support can request a correction, but cannot rewrite payment or tax history.

Route exceptions to the right owner

A failed product claim returns to catalogue. A safety signal pauses the affected offer and goes to the safety specialist. A refused tracking choice remains refused; the ICO's final storage and access guidance supplies the current PECR boundary.

Account compromise, unexpected privilege or corrupted events go to security. Preserve logs and use an incident identifier. NCSC secure online-service guidance treats logging, transaction monitoring and incident management as distinct operating capabilities.

Correct, roll back and close

A correction creates a replacement version without deleting the earlier record. Rollback stops new writes, restores the last accepted product state and continues open-order obligations. Test an isolated export and restore with fictional data before launch.

Close only when every product and order event is accepted, deliberately rejected or assigned to a visible queue. Remove obsolete access, retain records under the approved schedule and record deletion evidence. Any failed consumer, safety, tax, privacy, security, accessibility or exit gate keeps the workflow on HOLD.