Guide chapters
00 - How to use the guide01 - First choose the business and responsibility model, then build the marketplace02 - Construction plan: what must exist and when03 - Responsibility Matrix: Operator, Seller, and Suppliers04 - Seller Onboarding: Whom to Allow to Sell05 - Product card: information without which an offer cannot be published06 - GPSR: Product Safety in Practice07 - Product Category Gates08 - BDO, packaging, and EPR: who is actually responsible09 - Consumer Law: Sale, Withdrawal, and Complaint10 - Prices, Promotions, Ranking, Advertising, and Reviews11 - Payments, Payouts, VAT, and Sales Documents12 - GDPR without myths: what to record, where, and on what basis13 - DSA: reporting, moderation, and seller traceability14 - P2B: fair rules for business users15 - DAC7: seller data and annual reporting16 - E-commerce accessibility from June 28, 202517 - Cybersecurity and KSC/NIS218 - Retention: How long to store data and evidence19 - Post-launch operations: calendar and owners20 - Four business models - specific decisions21 - Document and Procedure Package to Prepare22 - GO / NO-GO Checklist Before Launch23 - Most Common Misconceptions24 - Sources and Update Principle§ - Important Disclaimer Regarding the Nature of the Material
Chapter 02
Construction plan: what must exist and when
Stage A - before signing an agreement with the first seller#
- Approved responsibility model and list of allowed categories.
- Agreement and terms and conditions for sellers, covering P2B, division of responsibilities, product documents, BDO, DAC7, payouts, complaints, recalls, and penalties.
- Seller verification process and the ability to retain documents and decision history. In MVP, this can be fields/statuses of an existing seller account and files in a controlled storage – a separate module is not required.
- Agreement with a payment provider supporting marketplaces.
- DSA procedure: content/product notifications, moderation, justification of decisions, and appeals to the extent required.
- GPSR procedure: blocking, notification, recall, buyer notification, and contact with the authority.
- Privacy policy, GDPR role map, data processing agreements, and record of processing activities.
- DAC7 decision: whether the operator is a reporting operator and what data it will collect.
Stage B - before publishing the first offer#
- Product card enforcing seller, manufacturer, responsible person in the EU, product identification, warnings, and category information.
- Category approval process and blocking publication if information is missing.
- Ability to attach compliance documents and proof of origin to the seller or offer. In MVP, existing file storage with access control and record association is sufficient.
- Visible indication of whether the seller is a business or a private individual.
- Rules for ranking, advertisements, reviews, and promotions.
- Price change history and calculation of the lowest price over 30 days. In MVP, this can be a record of each change and a query performed during promotions; a separate pricing engine is not necessary.
Stage C - before accepting the first paid order#
- Checkout indicating the seller for each item, total price, fees, delivery, and payment obligation.
- Checkbox for accepting terms and conditions with proof allowing reconstruction of the person, time, and applicable version – not as marketing consent. The law does not mandate a separate technical table.
- Separate, voluntary marketing consents and a cookie panel blocking optional technologies until consent is given.
- Order snapshot: seller, product, price, offer, warnings, document versions, and proof of acceptance.
- Path for withdrawal, complaint, return, refund, and communication with the seller.
- Payment processing, payouts, holds, refunds, and chargebacks by the PSP.
- Account security: MFA for administrators and high-risk local operations, roles, logs, and backups. Payout operations performed solely within Stripe are secured by Stripe.
Stage D - before public scaling#
- Availability report and the entire purchasing process available.
- Established schedule for audits of offers, sellers, BDO, DAC7, security, and retention.
- Event view: blocked products, missing documents, notifications, deadlines, complaints, recalls, and incidents. Initially, this can be a saved query or a controlled export/spreadsheet; a dedicated dashboard is only needed for a larger volume of cases.
- Business continuity plan, backup recovery, and data breach handling.
- Assessment of DSA, PAD, and NIS2 thresholds with an alert before losing exemption or reaching a threshold.
MVP Matrix – the simplest implementation for the entire guide#
| Area | Simplest MVP in existing system | Expand only when… |
|---|---|---|
| Responsibility model | One approved document and agreement versions | the operator adds import, own brand, fulfillment, own sales, or a new country |
| Seller onboarding | Profile fields/statuses, files attached to the account, check result and date; Stripe as KYC/account source | number of exceptions and re-verifications causes omissions |
| Product Card | 5–7 common blocks, category fields only when relevant, clear label photo and publication status | common cards, multiple variants or high-risk categories require automatic validation |
| GPSR | Current support form with case type, UUID, email for authorities, offer block status, and order query | recalls cover multiple offers, batches, sellers, and teams |
| Category Gateways | Employee checklist, conditional fields, and manual approval | manual review does not fit before publication or documents frequently expire |
| BDO/EPR | Status declaration, BDO number and scope only when relevant, registry check result, and reminder | operator handles fulfillment, own packaging, cross-border sales, or PPWR requires additional checks |
| Returns and Complaints | Same request system with type, UUID, order, attachments, confirmation, and deadline | manually tracking deadlines ceases to be reliable |
| Prices and Promotions | Price change history over time and a query covering at least 30 days | a large number of variants, channels, and promotions requires a central engine |
| Payments and Payouts | Stripe Connect; identifiers, statuses, reconciliation with orders, and history view within the platform | operator changes the money flow or starts performing local operations affecting payouts |
| Terms and Conditions, Acceptances, and Consents | Immutable document versions and existing account/order events linked to the version; CMP for cookies | the current record overwrites history or multiple systems do not provide a single proof |
| DSA and Moderation | Current form with DSA type, required information, UUID, decision history, and emails | reporting, appeals, and the number of cases exceed the capacity of a standard queue |
| P2B | Versioned terms and conditions, email proof, explanation/appeal ticket | operator loses exemption or needs a formal system for complaints and mediators |
| DAC7 | Profile data + Stripe + controlled export and spreadsheet according to the saved method | manual reconciliation does not ensure completeness before the end of the year |
| Availability | Manual test of the full path, list of errors in a standard task system, and re-test | frequent releases require automated regression tests and continuous monitoring |
| Cybersecurity | Admin MFA, roles, logs, updates, backup, and contact list; Stripe secures hosted payouts | NIS2 qualification or scale requires a formal management and reporting system |
| Retention | Approved schedule of deadlines, periodic list for deletion, legal hold flag, and execution confirmation | volume makes secure manual review impossible |
| Management Report | Saved queries and a controlled spreadsheet with deadlines/deficiencies | multiple teams need data on an ongoing basis and the spreadsheet becomes inconsistent |
Need to implement these processes in a real marketplace?
I design multi-vendor platforms with onboarding, payments, moderation, and operational workflows.
Explore marketplace development