Product Authenticity Verification for Marketplaces: A Four-Gate Pipeline

A marketplace proves products are genuine by refusing stock until it passes evidence gates, not by trusting seller claims. A practical pipeline has four gates: an importer or authorised-distributor invoice matched to the batch, a physical inspection, a product-record check, and a batch and expiry record that buyers can look up. TheSkinProof, the founder's own marketplace, runs this four-gate pipeline across 5 portals.

If you would rather have it built for you, see how RAITHub would build this below.

What does "verified authentic" actually mean on a marketplace?

It means the marketplace holds evidence, per batch, that the units came from the brand's legitimate supply chain, and that a named person reviewed that evidence before the listing went live. "Authentic" is a claim about provenance. It is not a claim about how well a product works, and a verification badge should never be worded as one.

The weak version is a badge on the seller's profile: "trusted seller". That verifies a person, not the stock. A seller can be real, registered and well reviewed and still buy one bad carton from a grey-market supplier. The strong version ties evidence to the batch (also called the lot): the production run printed on the pack. Every unit you sell belongs to a batch, every batch has a paper trail, and that is the level where proof has to live.

What documents should a marketplace ask suppliers for?

Ask for documents that a counterfeiter finds hard to produce and that you can cross-check against each other. The table below is the set we would start with for branded consumer goods.

Document	What it proves	What to match it against
Importer or distributor invoice	The batch was bought from the supply chain, not a reseller of unknown origin	Batch code, quantity, product, seller's legal name, importer registration
Authorised-distributor letter from the brand	The upstream supplier is allowed to sell the brand	Supplier name on the invoice; expiry date of the letter
Customs or import papers, where goods are imported	The goods entered the country through a declared route	Invoice line items and tariff (HS) codes
Inspection photos taken by your team	The physical cartons match the paperwork	Batch and expiry printed on the pack; seals, holograms and print quality against a known-good reference

Store a hash of every uploaded file. If a document is later disputed, you can show that the file you reviewed is byte-for-byte the file you still hold. Keep supplier invoices private: they contain prices and supplier relationships, so buyers see the verification result, never the document.

How do you check sellers before they can list?

Seller onboarding is the first filter, and it is separate from product verification. Collect the legal entity name, registration or trade licence, tax ID, a bank account in the same name, and a named contact. Verify them before the first payout, and re-check them on a schedule.

In some markets this is a legal duty, not a choice. In the United States, the INFORM Consumers Act requires online marketplaces to collect and verify bank, tax ID and contact details from "high-volume" third-party sellers, defined as 200 or more separate sales and $5,000 or more in gross revenue in a continuous 12-month period. Marketplaces must do this within 10 days, and sellers must recertify at least once a year (FTC: INFORM Consumers Act guidance). Other regions have their own trader-identification rules. This is general information; confirm what applies to your marketplace with your legal adviser.

Design the seller record so that verification status is a field the system enforces, not a note in a spreadsheet. A seller whose documents have expired should lose the ability to publish new batches automatically.

What does a four-gate authenticity pipeline look like?

Each gate is a separate decision, recorded by a named reviewer, and a batch is sellable only when every gate has passed. This is the shape TheSkinProof uses; the gate names are its own.

Gate	Evidence	Who decides	Fails when
1. Invoice	Authorised-distributor invoice matched on batch, product and importer registration	Document reviewer	No invoice, a mismatched batch code, or a supplier not on the brand's authorised list
2. Physical	Photos of every carton; seals, holograms and print checked against the brand record	Warehouse team	Packaging differs from the reference, or seals are broken
3. Product record	Product details cross-checked against manufacturer and standards records and banned-substance lists	Catalogue reviewer	The product or manufacturer cannot be matched to an official record
4. Batch code	Batch and expiry recorded per unit and published for buyer lookup	System, after gates 1 to 3	Batch or expiry missing, or already expired

Gate 3 is a record check, not a lab test. If your category needs laboratory testing, that is a separate, accredited service, and your marketplace should store its certificates as another document type rather than claim to do the testing itself.

The order matters. Paperwork costs the least to check, so it goes first; a batch with no invoice should never reach the warehouse queue. The batch record is published last, so a buyer can never look up a batch that has not finished review.

How do you build the review workflow and audit trail?

Model batches, documents and decisions as separate tables, and make the decision log append-only. The database, not the admin UI, should be what guarantees that history cannot be rewritten. A minimal PostgreSQL schema:

CREATE TABLE batches (
  id          bigserial PRIMARY KEY,
  product_id  bigint NOT NULL REFERENCES products(id),
  seller_id   bigint NOT NULL REFERENCES sellers(id),
  batch_code  text   NOT NULL,
  expiry_date date,
  status      text   NOT NULL DEFAULT 'pending'
              CHECK (status IN ('pending', 'verified', 'rejected', 'revoked')),
  UNIQUE (product_id, batch_code)
);

CREATE TABLE batch_documents (
  id          bigserial PRIMARY KEY,
  batch_id    bigint NOT NULL REFERENCES batches(id),
  kind        text   NOT NULL
              CHECK (kind IN ('importer_invoice', 'distributor_letter', 'customs', 'inspection_photo')),
  file_key    text   NOT NULL,
  sha256      text   NOT NULL,
  uploaded_by bigint NOT NULL,
  uploaded_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE verification_events (
  id          bigserial PRIMARY KEY,
  batch_id    bigint NOT NULL REFERENCES batches(id),
  gate        text   NOT NULL CHECK (gate IN ('invoice', 'physical', 'record', 'batch')),
  decision    text   NOT NULL CHECK (decision IN ('pass', 'fail')),
  reviewer_id bigint NOT NULL,
  note        text,
  created_at  timestamptz NOT NULL DEFAULT now()
);

-- The app can add history, never change it.
REVOKE UPDATE, DELETE ON verification_events FROM app_user;

The rule "sellable only when every gate passed" belongs in one function that every publish path calls: the seller portal, the admin console and any import script.

type Gate = 'invoice' | 'physical' | 'record' | 'batch'
type VerificationEvent = { gate: Gate; decision: 'pass' | 'fail'; createdAt: Date }

const GATES: Gate[] = ['invoice', 'physical', 'record', 'batch']

export function isBatchSellable(events: VerificationEvent[], expiry: Date | null, now = new Date()) {
  if (!expiry || expiry <= now) return false
  // The latest decision per gate wins, so a re-review can overturn an old pass.
  const latest = new Map<Gate, VerificationEvent>()
  for (const e of events) {
    const prev = latest.get(e.gate)
    if (!prev || e.createdAt > prev.createdAt) latest.set(e.gate, e)
  }
  return GATES.every((g) => latest.get(g)?.decision === 'pass')
}

Two rules stop verification from drifting after go-live. First, when a seller edits a live listing's batch, images or product details, the change goes back into review while the approved version stays on sale. TheSkinProof's seller portal works this way, with product drafts that carry their verification documents. Second, stock can only be received against a verified batch, so a seller cannot top up a verified listing with units from an unverified one. Reserving that stock safely at checkout is a separate problem, covered in stopping overselling with stock reservation inside the order transaction.

Should buyers be able to look up a batch number?

Yes. A public lookup turns your back-office work into something a buyer can check. The buyer types the batch code from the pack, or scans a code on the insert, and sees the product, the date the batch passed review and its expiry date.

• Show the result, not the evidence. "Batch 24A17, verified 3 March, expires June 2028" is enough. Never expose invoices, supplier names or prices.
• Say what an unknown code means. "We have no record of this batch" is different from "this product is fake". Give the buyer a way to report it.
• Rate-limit the endpoint so nobody can enumerate your batch list.
• Emit the batch as structured data on the product page, so search engines and answer engines read the same facts the buyer sees.

Batch codes are a weaker signal than unit-level serial codes, because one batch code is shared by thousands of units and can be copied. Unit-level codes need the brand's cooperation. Amazon's Transparency programme, for example, puts a unique code on each unit and charges brands $0.05 per code for the first million a year, falling to $0.01 above ten million; it requires a registered trademark and a GTIN per product (Amazon: Transparency). For a marketplace that does not control the packaging, verified batches plus inspection is the realistic level.

How do returns and refund guarantees fit in?

A guarantee is only believable if there is a process behind it. When a buyer reports a suspected fake:

1. Open a case linked to the order line and its batch.
2. Collect the returned unit and inspect it against the batch's inspection photos.
3. If it fails, mark the batch revoked. Every listing that draws on that batch comes off sale at once, and every other buyer of that batch can be contacted.
4. Refund on the published terms, and record the outcome as a verification_events row so the history explains itself.

TheSkinProof offers a 2x money-back guarantee if a product is ever proven counterfeit. The guarantee works because every unit traces back to a reviewed batch, so a claim can be checked rather than argued. Keep returned goods out of sellable stock until they pass inspection; a returned unit that skips review is the easiest way to undo the whole pipeline.

Buy, build or hire?

Option	Typical cost	Choose this when	The catch
Off-the-shelf: sell through a marketplace with a brand programme, such as Amazon Transparency	$0.05 to $0.01 per unit code (Amazon)	You are the brand owner and sell on Amazon	Brand-side only; a multi-brand marketplace cannot enrol other people's products
No-code or template: a hosted store or marketplace builder, with verification run by hand	Shopify from $19 a month billed yearly to Plus from $2,300 a month (Shopify pricing); Sharetribe from $39 a month to build and $199 a month billed yearly to go live (Sharetribe pricing)	You are testing demand with a few vetted sellers and can review documents in a shared folder	No per-batch gate, so a listing can go live without evidence; the audit trail is wherever your team remembers to write it
Custom build	A fixed quote for your scope	Authenticity is the product: you need batch-level gates, an append-only audit log, a buyer lookup and revocation that delists stock automatically	A real build, with the testing that a trust promise needs

For the wider comparison, see Sharetribe vs a custom marketplace.

How long does it take to build yourself, and what is the risk?

Our estimate for an experienced full-stack developer adding this to an existing marketplace: 3 to 5 weeks for document upload with hashing, a review queue with per-gate decisions, an append-only audit log, publish gating, revocation and a public lookup page. Add time if you also need a seller onboarding flow from scratch.

The main risk is a second path around the gate. A bulk import script, an admin "quick edit" or a stock top-up that does not call the same check quietly lets unverified units onto a verified listing. Test every write path against the gate, not just the happy path in the seller portal.

Why RAITHub for this

• We built and run a pipeline like this. TheSkinProof is the founder's own verified-skincare marketplace, not a client project: a four-gate authenticity pipeline, 5 role-based portals (storefront, admin, seller, warehouse and auth), 217 API endpoints and 750+ automated tests. The details are in the TheSkinProof case study.
• QA-first. The gates, the revocation path and every write path around them get automated tests in CI, because a trust promise that fails silently is worse than none.
• Warehouse included. Verification only holds if picking and packing respect it; TheSkinProof's warehouse portal has a picking queue and photo verification before dispatch.

When you don't need us

• You are the brand and sell on Amazon. Brand Registry and Transparency solve this on that channel.
• You have a handful of sellers you know personally. A hosted store and a document checklist your team follows by hand is enough until volume makes manual review the bottleneck.
• Your developers already have a review queue. Adding gates, hashing and an append-only log to it is a well-understood change; the schema above is a fair start.

How RAITHub would build this

• Seller onboarding: entity, licence, tax and bank checks, document expiry and scheduled recertification.
• Batch verification: document upload with hashing, a per-gate review queue for your document, warehouse and catalogue teams, and an append-only audit log.
• Publish and stock gating: one sellable-check used by every write path, with edit-while-live re-review.
• Buyer trust surfaces: a rate-limited batch lookup page, structured data on product pages, and a counterfeit-claim flow that revokes a batch and delists it in one step.

Timeline: a new marketplace MVP with this pipeline as its core fits our 4 to 6 week fixed-scope MVP range; adding it to an existing platform's backend is typically 6 to 12 weeks, depending on how many write paths need gating. See SaaS development and the ecommerce industry page, and for the full platform picture, building a marketplace or B2B store.

You receive: automated tests and CI, handover docs and runbooks for your review team, and full IP in your name under NDA. We sign NDAs and DPAs and work inside your controls; production data stays in your own cloud account, and development uses synthetic data.

Next step: book the free 15-minute technical audit. Bring your current listing flow and the documents your sellers already provide, and we will follow up with a written fixed quote.

Frequently asked questions

How do online marketplaces verify that products are authentic?

The reliable way is per batch: match the importer or authorised-distributor invoice to the batch code, inspect the physical cartons, check the product against official records, and publish the batch only after every check has passed and been recorded.

Is verifying the seller enough to stop counterfeits?

No. Seller checks confirm who you are paying, not where their stock came from. A genuine seller can still buy a bad batch, so evidence has to attach to each batch as well as to the seller.

What is the difference between a batch number and a serial number?

A batch or lot number identifies a production run shared by many units. A serial number is unique to one unit. Serial codes are stronger proof, but they need the brand to print them, so most multi-brand marketplaces verify at batch level.

Should a batch lookup page show the supplier invoice?

No. Show the result: product, verification date and expiry. Invoices contain supplier names and prices, so keep them private and available only to your review team and auditors.

What happens when a verified batch turns out to be fake?

Revoke the batch, which should take every listing drawing on it off sale at once, contact affected buyers, refund on your published terms, and record the decision in the audit log.

Does the US require marketplaces to verify sellers?

For high-volume third-party sellers, yes: the INFORM Consumers Act requires marketplaces to collect and verify bank, tax and contact details. This is general information; confirm your obligations with your legal adviser.