Co naprawdę trzeba wdrożyć w MVP
Kiedy lista obowiązków zaczyna wyglądać jak specyfikacja Amazona
Kiedy pierwszy raz zbierzesz w jednym miejscu skróty takie jak GPSR, DSA, RODO, BDO, DAC7, P2B, dostępność i ceny z ostatnich 30 dni, łatwo dojść do wniosku, że mały marketplace powinien od początku zbudować infrastrukturę wielkości Amazona: osobny panel do zgłoszeń, rejestr akceptacji regulaminu, moduł wycofań produktów, repozytorium dokumentów, rozbudowany formularz produktowy i własny system weryfikacji sprzedawców, jeszcze zanim platforma przyjmie pierwsze zamówienie.
Taki zakres zwykle wynika z pomieszania dwóch rzeczy: rezultatu, który przepisy każą osiągnąć i docelowej architektury dużej platformy. Przepisy mówią najczęściej, że masz potrafić coś wykazać, udostępnić, znaleźć, zablokować, przekazać albo rozpatrzyć w określonym czasie. Rzadko mówią, w jakiej tabeli ma to leżeć i jak ma wyglądać ekran administratora.
W poprzednim artykule opisałem szeroki obraz obowiązków marketplace w Polsce, od RODO przez prawa konsumenta po weryfikację sprzedawców i bezpieczeństwo płatności. Zakładam tutaj, że już to wiesz i odpowiadam na inne pytanie: jak przełożyć te obowiązki na rozsądne MVP, bez projektowania infrastruktury dla milionów ofert. Pełny przewodnik operacyjny, który obiecywałem, jest dostępny pod appcrates.pl/marketplace-guide. Tutaj skupiam się na kilku miejscach, w których decyzja architektoniczna waży najwięcej.
WAŻNE. Materiał ma charakter wyłącznie informacyjny i edukacyjny. Przedstawia autorską interpretację ogólnych wymogów i możliwych sposobów wdrożenia. Nie stanowi porady prawnej, podatkowej ani indywidualnej oceny konkretnej platformy lub produktu.
Zasada, która upraszcza cały projekt
Przy każdym wymaganiu warto zadać pięć pytań.
- Czy ten obowiązek dotyczy mnie już teraz? Część obowiązków zależy od roli platformy, statusu sprzedawcy, kategorii produktu albo wielkości przedsiębiorstwa.
- Jaki rezultat muszę osiągnąć? Na przykład odtworzyć treść regulaminu, przyjąć zgłoszenie produktu, zidentyfikować kupujących albo wykazać historię ceny.
- Czy istniejący system już przechowuje potrzebne informacje? Często tak, w koncie, zamówieniu, zgłoszeniu, pliku, logu albo w Stripe.
- Czego brakuje do wiarygodnego dowodu? Zwykle wersji, czasu, statusu, powiązania z ofertą albo historii zmian.
- Kiedy ręczna obsługa przestanie działać? Dopiero wtedy pojawia się uzasadnienie dla osobnego modułu i automatyzacji.
Jeżeli informacja ma trwały identyfikator i czas utworzenia, nie jest bez śladu nadpisywana, i można ją wyszukać oraz powiązać z właściwą osobą, ofertą albo zamówieniem, zwykle wystarczy rozbudować obecny proces o kilka elementów. Nie trzeba kopiować tych samych danych do osobnej tabeli zgodności, żeby wyglądały poważniej.
Regulamin: dowód wersji bez osobnej tabeli zgodności
Platforma musi umieć wykazać, jaki regulamin był udostępniony użytkownikowi i jaka wersja obowiązywała w danym momencie. Prawo tego wymaga, ale nie wymaga konkretnie tabeli terms_acceptances ani kopiowania całego regulaminu do każdego zamówienia. Pełniejszy opis samego obowiązku dokumentacyjnego znajdziesz w poprzednim artykule, tu chodzi o to, jak taki dowód zapisać bez rozrastania modelu danych, co rozwijam też w rozdziale o pakiecie dokumentów w przewodniku.
Każda wersja regulaminu może być zachowana jako niezmienny plik albo wersja w CMS, z własnym identyfikatorem i datą obowiązywania. Konto albo zamówienie zapisuje wtedy tylko identyfikator tej wersji i czas akceptacji, a po zmianie regulaminu stara treść nadal jest możliwa do odtworzenia. Jeżeli historia konta już zapisuje zdarzenia, można dodać do niej identyfikator wersji. Jeżeli zamówienie przechowuje snapshot checkoutu, można wykorzystać ten sam mechanizm. Osobna tabela staje się potrzebna dopiero wtedy, gdy obecna struktura nadpisuje dane albo nie pozwala wiarygodnie odtworzyć zdarzenia.
Akceptację regulaminu warto też oddzielić od zgody marketingowej. Pierwsza jest oświadczeniem związanym z umową, druga ma być dobrowolna i możliwa do cofnięcia. Jeden obowiązkowy checkbox nie powinien załatwiać obu naraz.
Onboarding sprzedawcy: dane od Stripe nie muszą trafiać do twojej bazy
Mały marketplace często korzysta ze Stripe Connect lub podobnego rozwiązania. Dostawca płatności prowadzi onboarding płatniczy, sprawdza tożsamość w swoim zakresie i przechowuje rachunek wypłat, o czym pisałem szerzej w poprzednim artykule, w części o weryfikacji sprzedawców.
Marketplace nadal musi wiedzieć, kto sprzedaje, jaki ma status, gdzie działa, jakie produkty oferuje i jaką rolę pełni wobec produktu. Rachunek bankowy sprzedawcy nadal jest elementem weryfikacji, tylko że weryfikacja nie oznacza kopiowania pełnego IBAN-u i dokumentów KYC do własnej bazy. W prostym modelu platforma może przechowywać identyfikator konta Stripe, status zakończenia onboardingu, status możliwości przyjmowania płatności i wypłat, podstawowe dane firmy potrzebne platformie, oraz dane podatkowe i produktowe, których Stripe nie zbiera w potrzebnym zakresie. Pełny rachunek może pozostać u dostawcy płatności, jeżeli operator nie potrzebuje go do konkretnego własnego obowiązku. W DAC7 identyfikator rachunku raportuje się w zakresie, w jakim jest dostępny operatorowi, więc zbieranie IBAN-u wyłącznie po to, aby uczynić go dostępnym, nie jest konieczne.
Zakres obowiązków DSA dotyczących identyfikowalności przedsiębiorców może się zmienić wraz ze wzrostem platformy. To dobry przykład wymagania, które powinno mieć wyraźny próg skalowania, zamiast obciążać każdy bootstrap od pierwszego dnia. Cały proces, w tym to, kogo w ogóle dopuścić do sprzedaży, opisuję w rozdziale o onboardingu sprzedawcy w przewodniku.
Karta produktu nie musi mieć stu pól
GPSR wymaga, aby oferta internetowa zawierała określone informacje o produkcie, producencie, osobie odpowiedzialnej w UE i bezpieczeństwie. Z tego nie wynika uniwersalny formularz z wagą, wymiarami, składem, pojemnością, numerem serii i certyfikatem CE dla każdego przedmiotu. Dokładniejszy opis samego obowiązku jest w rozdziale o GPSR.
Rozsądny formularz ma dwie warstwy. Warstwa wspólna obejmuje kilka elementów potrzebnych dla typowego fizycznego produktu: nazwę i zdjęcie, identyfikację produktu, producenta, osobę odpowiedzialną w UE jeżeli jest wymagana, oraz istniejące ostrzeżenia lub informacje bezpieczeństwa. Warstwa kategorii pojawia się dopiero po wyborze rodzaju produktu, opisana szerzej w rozdziale o bramkach kategorii. Kosmetyk może wymagać INCI i osoby odpowiedzialnej, zabawka informacji związanych z CE i ostrzeżeń, żywność składu i alergenów, ceramiczny kubek informacji właściwych materiałom do kontaktu z żywnością. Sprzedawca świecy nie powinien oglądać formularza przygotowanego dla elektroniki.
Zdjęcie etykiety może częściowo wystarczyć, bo czytelne zdjęcie przenosi skład, oznaczenia i dodatkowe instrukcje. Najważniejsze dane, producent, osoba odpowiedzialna, identyfikacja i ważne ostrzeżenia, lepiej pokazać także jako krótkie informacje na stronie, żeby były widoczne na telefonie, dostępne dla czytnika ekranu i możliwe do wyszukania.
Rękodzieło nie wymaga wymyślania fabrycznego numeru partii, którego nie ma. Jednostkowy obraz, kubek albo biżuteria mogą być identyfikowane nazwą, twórcą, rokiem i unikalnym numerem egzemplarza. Produkt używany albo vintage potrzebuje innej ścieżki niż nowy towar, samo słowo vintage nie zamienia zwykłego używanego urządzenia w antyk.
Jeden formularz może obsłużyć wsparcie, GPSR i DSA
Punkt kontaktowy dla organów nie wymaga osobnego portalu dla urzędników. Najprostsze rozwiązanie to jedna publiczna strona kontaktowa, jeden backend zgłoszeń i kilka wyraźnych typów spraw: wsparcie techniczne, zwrot lub reklamacja, bezpieczeństwo produktu, nielegalna oferta lub treść, organ publiczny lub nakaz.
Dla organów można opublikować alias w rodzaju safety@twojadomena.pl albo legal@twojadomena.pl, trafiający do tej samej skrzynki i tej samej tabeli co zwykłe zgłoszenia. Ważne, aby kontakt nie wymagał konta, był aktualny, prowadził do człowieka i był właściwie obsługiwany. Dane punktu GPSR trzeba też podać przy rejestracji platformy w Safety Gate.
Dla zgłoszenia produktu przydadzą się link lub numer oferty, opis ryzyka, dane kontaktowe i załącznik. DSA wymaga dodatkowo informacji pozwalających ocenić zarzucaną bezprawność i oświadczenia zgłaszającego o działaniu w dobrej wierze, co opisuję szerzej w rozdziale o moderacji DSA.
Jeżeli każdy request w systemie już ma UUID, to jest to identyfikator sprawy. Nie trzeba tworzyć drugiej numeracji tylko dlatego, że zgłoszenie trafiło do kategorii GPSR. UUID powinien pojawić się w potwierdzeniu e-mail i pozwalać odnaleźć treść, czas, status, decyzję oraz komunikację. Dedykowany panel bezpieczeństwa zaczyna mieć sens dopiero wtedy, gdy jedno wycofanie obejmuje wiele ofert, partii, sprzedawców i zespołów, a zwykła kolejka przestaje gwarantować terminy.
Lista kupujących też może być zapytaniem
Gdy produkt okazuje się niebezpieczny, platforma musi umieć ustalić, kto go kupił, i przekazać odpowiednie informacje. Nie oznacza to konieczności stałego utrzymywania osobnej kopii listy kupujących do GPSR.
Jeżeli pozycje zamówień są powiązane z produktem lub ofertą, platforma może wyszukać właściwe zamówienia, wyeksportować wynik i wysłać komunikat. Dla produktów z partiami warto przechowywać numer partii, dla jednostkowego rękodzieła wystarczy identyfikator konkretnej oferty lub egzemplarza. Więcej o samym obowiązku identyfikowania kupujących przy wycofaniu produktu piszę w rozdziale o GPSR.
Dobrym testem jest sprawdzenie, czy w ciągu kilku godzin da się przejść od produktu do sprzedawcy, wszystkich ofert i kupujących. Brak takiej ścieżki zwykle wynika z niespójnych powiązań w podstawowym modelu zamówień, rzadziej z braku osobnego panelu do zarządzania wycofaniami.
BDO: najpierw status i rola, potem numer
Formularz BDO, który pyta każdego sprzedawcę o numer i blokuje konto, gdy pole pozostaje puste, jest prosty technicznie, ale nie odpowiada rzeczywistemu zakresowi obowiązku.
Najpierw trzeba rozróżnić okazjonalną sprzedaż prywatną, działalność nierejestrowaną, przedsiębiorcę, importera albo podmiot wprowadzający określoną grupę produktu, oraz podmiot pakujący i wprowadzający produkt w opakowaniu. Osoba prywatna sprzedająca własny używany przedmiot nie staje się automatycznie podmiotem BDO. Osoba prowadząca prawidłową działalność nierejestrowaną znajduje się w innym położeniu niż zarejestrowany przedsiębiorca. Rękodzielnik-przedsiębiorca, który pakuje własny produkt w pudełko i wysyła go klientowi, może mieć obowiązki opakowaniowe mimo niewielkiej skali.
MVP platformy to deklaracja statusu, kilka pytań o import, opakowania i grupę produktu, oraz pole BDO uruchamiane tylko wtedy, gdy odpowiedzi wskazują na taki obowiązek. Wynik sprawdzenia numeru można zapisać w profilu sprzedawcy. Kalkulator mas opakowań nie jest potrzebny od razu, jeżeli platforma sama nie prowadzi fulfillmentu. Pełniejszy opis progów i obowiązków opakowaniowych jest w rozdziale o BDO i opakowaniach.
DAC7 może zacząć się od kontrolowanego eksportu
DAC7 wymaga danych sprzedawców, agregatów transakcji i corocznego raportowania, ale pierwszą funkcją platformy nie musi być rozbudowany dashboard podatkowy.
Przy niewielkiej liczbie sprzedawców można zacząć od kontrolowanego procesu: dane tożsamościowe i podatkowe pochodzą z profilu sprzedawcy, dane transakcji i refundacji z zamówień oraz Stripe, uzgodniony eksport jest sprawdzany kwartalnie, obliczenia wykonywane są według zapisanej metody, a końcowy raport, potwierdzenie wysyłki i informacja dla sprzedawcy są archiwizowane.
Arkusz sam w sobie działa dobrze, jeżeli ma właściciela, wersję, kontrolę zmian i możliwość odtworzenia obliczeń. Bez tych elementów staje się ryzykiem, bo ręczne uzgodnienie zaczyna generować pominięcia albo nie mieści się w terminie, i wtedy potrzebna jest automatyzacja. Cały proces raportowania, wraz z terminami i zakresem danych, opisuję w rozdziale o DAC7.
Bezpieczeństwo: chroń to, co kontrolujesz
Jeżeli zmiana rachunku wypłat odbywa się wyłącznie na hostowanym ekranie Stripe, Stripe zabezpiecza tę operację swoim uwierzytelnieniem i mechanizmem podwyższonej weryfikacji. Platforma nie musi kopiować tego ekranu ani przechowywać rachunku tylko po to, żeby dodać własne MFA. Ten fragment rozwija ogólną checklistę bezpieczeństwa technicznego z poprzedniego artykułu o konkretny podział, co faktycznie leży po stronie operatora platformy.
Lokalne operacje, które mogą wyrządzić szkodę, nadal trzeba chronić: konto administratora, zmianę ról i uprawnień, zmianę właściciela konta sprzedawcy, podpięcie albo zmianę powiązania z kontem PSP, masową zmianę cen i ofert, usunięcie lub przywrócenie zablokowanego produktu.
Dla małej platformy minimum to MFA administratorów, ograniczone role, aktualizacje, bezpieczne sekrety, log ważnych zmian, kopie zapasowe i przetestowane odtworzenie. Monitoring może początkowo oznaczać alerty od dostawców i codzienny przegląd najważniejszych zdarzeń, bez budowania własnego centrum operacji bezpieczeństwa. Podobnie wygląda bezpieczeństwo łańcucha dostaw, bo chodzi przede wszystkim o hosting, chmurę, dostawcę płatności, e-mail, helpdesk, analitykę i oprogramowanie. Kurier sprzedawcy staje się pełnym procesem operatora dopiero wtedy, gdy platforma sama organizuje dostawę lub fulfillment. Pełny zakres obowiązków cyberbezpieczeństwa i NIS2 opisuję w osobnym rozdziale.
Co naprawdę powinno istnieć przed pierwszym zamówieniem
Przed startem liczy się kilka działających podstaw: jasna informacja, kto jest sprzedawcą każdej pozycji, poprawny checkout z pełną ceną, płatności marketplace obsługiwane przez właściwego PSP, wersjonowane regulaminy z dowodem akceptacji, formularz produktu z wymaganym minimum i bramkami kategorii, jeden formularz zgłoszeń z UUID, możliwość zablokowania oferty i znalezienia powiązanych zamówień, proces odstąpienia i reklamacji z pilnowaniem terminów, decyzja kogo obejmują BDO i DAC7, oraz podstawy RODO, cookies, bezpieczeństwa i retencji.
Każdy z tych punktów może być prosty, pod warunkiem że faktycznie działa. Zapis w regulaminie nie zastąpi pola, które ma być widoczne przed zakupem, checkbox bez zapisu wersji nie stworzy dowodu, formularz którego nikt nie sprawdza nie jest procedurą, a backup którego nigdy nie odtworzono jest tylko nadzieją. Pełną checklistę przed uruchomieniem, w formacie do przejścia punkt po punkcie, zebrałem w rozdziale go/no-go.
Co może poczekać do momentu skalowania
Na późniejszy etap zwykle można przesunąć dedykowany panel spraw GPSR, automatyczne rozpoznawanie podobnych ofert, osobny moduł reklamacji jeżeli zwykłe tickety zapewniają terminy, dashboard DAC7 jeżeli kontrolowany eksport jest kompletny, silnik retencji jeżeli mała baza jest okresowo i poprawnie obsługiwana, własny system KYC gdy właściwy zakres obsługuje Stripe, rozbudowany system reguł kategorii dopóki ręczna checklista jest niezawodna, oraz centralny panel zgodności jeżeli zapisane zapytania i raport okresowy pokazują wszystkie braki.
Granica jest prosta: rozbudowujesz rozwiązanie wtedy, gdy obecny proces przestaje być wiarygodny, nie mieści się w terminach, nie zapewnia właściwych uprawnień albo nowy próg prawny zwiększa zakres obowiązków.
Marketplace zgodny z wymaganiami nie musi wyglądać jak Amazon
Najważniejszą kompetencją na początku jest rozdzielenie trzech rzeczy: tego, co platforma musi wykonać już teraz, tego, co może wykonać sprzedawca albo dostawca taki jak Stripe, i tego, co stanie się potrzebne dopiero po wzroście, wejściu w nową kategorię, kraj, import albo fulfillment.
Dobrze zaprojektowane MVP realizuje wymogi najprostszym rozwiązaniem, które daje wiarygodny rezultat i dowód. Platforma może wystartować bez długu technologicznego wynikającego z chaosu, i bez kosztu infrastruktury przeznaczonej dla skali, której jeszcze nie ma.
Pełny przewodnik operacyjny, z rozdziałami dla GPSR, DSA, RODO, BDO, DAC7, P2B, dostępności, płatności, cen, cyberbezpieczeństwa i czterech modeli marketplace, jest dostępny pod appcrates.pl/marketplace-guide.
Jeśli budujesz taką platformę i wolisz, żeby ktoś wdrożył te procesy zamiast tłumaczyć je z przepisów, zobacz usługę budowy marketplace.
Podstawa i źródła: GPSR, rozporządzenie (UE) 2023/988. DSA, rozporządzenie (UE) 2022/2065. RODO, rozporządzenie (UE) 2016/679. Ministerstwo Finansów, DAC7/DPI. BDO, oficjalny serwis. UOKiK, prawa konsumenta i platformy.