Rozdziały przewodnika
00 - Jak korzystać z przewodnika01 - Najpierw wybierz model działalności i odpowiedzialności, potem buduj marketplace02 - Plan budowy: co musi istnieć i kiedy03 - Matryca odpowiedzialności: operator, sprzedawca i dostawcy04 - Onboarding sprzedawcy: kogo dopuścić do sprzedaży05 - Karta produktu: informacje, bez których oferta nie może się opublikować06 - GPSR: bezpieczeństwo produktów w praktyce07 - Bramki kategorii produktowych08 - BDO, opakowania i EPR: kto naprawdę ma obowiązek09 - Prawo konsumenckie: sprzedaż, odstąpienie i reklamacja10 - Ceny, promocje, ranking, reklamy i opinie11 - Płatności, wypłaty, VAT i dokument sprzedaży12 - RODO bez mitów: co zapisać, gdzie i na jakiej podstawie13 - DSA: zgłoszenia, moderacja i identyfikowalność sprzedawców14 - P2B: uczciwe zasady dla sprzedawców biznesowych15 - DAC7: dane sprzedawców i coroczne raportowanie16 - Dostępność e-commerce od 28 czerwca 2025 r.17 - Cyberbezpieczeństwo i KSC/NIS218 - Retencja: jak długo przechowywać dane i dowody19 - Operacje po uruchomieniu: kalendarz i właściciele20 - Cztery modele biznesowe - konkretne decyzje21 - Pakiet dokumentów i procedur do przygotowania22 - Checklista GO / NO-GO przed uruchomieniem23 - Najczęstsze błędne założenia24 - Źródła i zasada aktualizacji§ - Ważne zastrzeżenie dotyczące charakteru materiału
Rozdział 02
Plan budowy: co musi istnieć i kiedy
Etap A - przed zawarciem umowy z pierwszym sprzedawcą#
- Zatwierdzony model odpowiedzialności i lista dozwolonych kategorii.
- Umowa i regulamin dla sprzedawców, obejmujące P2B, podział obowiązków, dokumenty produktu, BDO, DAC7, wypłaty, reklamacje, wycofania i sankcje.
- Proces weryfikacji sprzedawcy oraz możliwość zachowania dokumentów i historii decyzji. W MVP mogą to być pola/statusy istniejącego konta sprzedawcy i pliki w kontrolowanym magazynie - osobny moduł nie jest wymagany.
- Umowa z dostawcą płatności obsługującym marketplace.
- Procedura DSA: zgłoszenia treści/produktów, moderacja, uzasadnienia decyzji i odwołania w wymaganym zakresie.
- Procedura GPSR: blokada, zgłoszenie, wycofanie, powiadomienie kupujących i kontakt z organem.
- Polityka prywatności, mapa ról RODO, umowy powierzenia i rejestr czynności przetwarzania.
- Decyzja DAC7: czy operator jest operatorem raportującym i jakie dane będzie zbierał.
Etap B - przed publikacją pierwszej oferty#
- Karta produktu wymuszająca dane sprzedawcy, producenta, osoby odpowiedzialnej w UE, identyfikację produktu, ostrzeżenia i informacje kategorii.
- Proces zatwierdzania kategorii oraz blokada publikacji przy brakach.
- Możliwość przypięcia dokumentów zgodności i dowodów pochodzenia do sprzedawcy lub oferty. W MVP wystarczy istniejący magazyn plików z kontrolą dostępu i powiązaniem rekordu.
- Widoczne oznaczenie, czy sprzedawca jest przedsiębiorcą czy osobą prywatną.
- Zasady rankingu, reklam, opinii i promocji.
- Historia zmian ceny i obliczenie najniższej ceny z 30 dni. W MVP może to być zapis każdej zmiany i zapytanie wykonywane przy promocji; osobny silnik cenowy nie jest konieczny.
Etap C - przed przyjęciem pierwszego płatnego zamówienia#
- Checkout wskazujący sprzedawcę dla każdej pozycji, łączną cenę, opłaty, dostawę oraz obowiązek zapłaty.
- Checkbox akceptacji regulaminu z dowodem pozwalającym odtworzyć osobę, czas i obowiązującą wersję - nie jako zgoda marketingowa. Prawo nie narzuca osobnej tabeli technicznej.
- Oddzielne, dobrowolne zgody marketingowe oraz panel cookies blokujący technologie opcjonalne do czasu zgody.
- Snapshot zamówienia: sprzedawca, produkt, cena, oferta, ostrzeżenia, wersje dokumentów i dowód akceptacji.
- Ścieżka odstąpienia, reklamacji, zwrotu, refundacji i komunikacji ze sprzedawcą.
- Obsługa płatności, wypłat, zatrzymań, zwrotów i chargeback przez PSP.
- Bezpieczeństwo kont: MFA administratorów i lokalnych operacji wysokiego ryzyka, role, logi oraz kopie zapasowe. Czynności wypłat wykonywane wyłącznie w Stripe zabezpiecza Stripe.
Etap D - przed publicznym skalowaniem#
- Raport dostępności i dostępny cały proces zakupowy.
- Ustalony harmonogram audytów ofert, sprzedawców, BDO, DAC7, bezpieczeństwa i retencji.
- Widok zdarzeń: produkty zablokowane, braki dokumentów, zgłoszenia, terminy, reklamacje, wycofania i incydenty. Na początku może to być zapisana kwerenda lub kontrolowany eksport/arkusz; dedykowany dashboard dopiero przy większej liczbie spraw.
- Plan ciągłości działania, odtwarzania z kopii oraz obsługi naruszenia danych.
- Ocena progów DSA, PAD i KSC wraz z alarmem przed utratą zwolnienia lub osiągnięciem progu.
Macierz MVP - najprostsza implementacja dla całego przewodnika#
| Obszar | Najprostsze MVP w istniejącym systemie | Rozbuduj dopiero, gdy… |
|---|---|---|
| Model odpowiedzialności | Jeden zatwierdzony dokument i wersje umów | operator dodaje import, markę własną, fulfillment, własną sprzedaż lub nowy kraj |
| Onboarding sprzedawcy | Pola/statusy profilu, pliki przypięte do konta, wynik kontroli i data; Stripe jako źródło KYC/rachunku | liczba wyjątków i ponownych weryfikacji powoduje pominięcia |
| Karta produktu | 5–7 wspólnych bloków, pola kategorii tylko gdy dotyczą, czytelne zdjęcie etykiety i status publikacji | wspólne karty, wiele wariantów lub kategorie wysokiego ryzyka wymagają walidacji automatycznej |
| GPSR | Obecny formularz wsparcia z typem sprawy, UUID, e-mail dla organów, status blokady oferty i zapytanie do zamówień | wycofania obejmują wiele ofert, partii, sprzedawców i zespołów |
| Bramki kategorii | Checklista pracownika, warunkowe pola i ręczne zatwierdzenie | ręczna kontrola nie mieści się przed publikacją albo dokumenty często wygasają |
| BDO/EPR | Deklaracja statusu, numer i zakres BDO tylko gdy dotyczą, wynik sprawdzenia rejestru i przypomnienie | operator prowadzi fulfillment, własne opakowania, sprzedaż transgraniczną albo PPWR wymaga dodatkowych kontroli |
| Odstąpienia i reklamacje | Ten sam system requestów z typem, UUID, zamówieniem, załącznikami, potwierdzeniem i terminem | ręczne pilnowanie terminów przestaje być niezawodne |
| Ceny i promocje | Historia zmian ceny z czasem oraz zapytanie liczące minimum 30 dni | duża liczba wariantów, kanałów i promocji wymaga centralnego silnika |
| Płatności i wypłaty | Stripe Connect; w platformie identyfikatory, statusy, uzgodnienie z zamówieniem i widok historii | operator zmienia przepływ pieniędzy lub zaczyna wykonywać lokalne operacje wpływające na wypłatę |
| Regulaminy, akceptacje i zgody | Niezmienne wersje dokumentów i istniejące zdarzenia konta/zamówienia powiązane z wersją; CMP dla cookies | obecny zapis nadpisuje historię albo wiele systemów nie daje jednego dowodu |
| DSA i moderacja | Obecny formularz z typem DSA, wymaganymi informacjami, UUID, historią decyzji i e-mailami | raportowanie, odwołania i liczba spraw przekraczają możliwości zwykłej kolejki |
| P2B | Wersjonowany regulamin, dowód e-maila, ticket wyjaśnienia/odwołania | operator traci zwolnienie lub potrzebuje formalnego systemu skarg i mediatorów |
| DAC7 | Dane profilu + Stripe + kontrolowany eksport i arkusz według zapisanej metody | ręczne uzgodnienie nie zapewnia kompletności przed końcem roku |
| Dostępność | Ręczny test pełnej ścieżki, lista błędów w zwykłym systemie zadań i ponowny test | częste wydania wymagają automatycznych testów regresji i stałego monitoringu |
| Cyberbezpieczeństwo | MFA admina, role, logi, aktualizacje, backup i lista kontaktów; Stripe chroni hostowane wypłaty | kwalifikacja KSC albo skala wymaga formalnego systemu zarządzania i raportowania |
| Retencja | Zatwierdzona tabela terminów, okresowa lista do usunięcia, flaga legal hold i potwierdzenie wykonania | wolumen uniemożliwia bezpieczną ręczną kontrolę |
| Raport zarządczy | Zapisane zapytania i kontrolowany arkusz z terminami/brakami | kilka zespołów potrzebuje danych na bieżąco i arkusz staje się niespójny |
Potrzebujesz wdrożyć te procesy w realnym marketplace?
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace