VTEX marketplace: architektura, onboarding sprzedawców i przewodnik po wdrożeniu

Ten przewodnik mapuje dwustronny model marketplace'u VTEX od początku do końca: od przepływu danych operator/sprzedawca, przez cykl życia sugestii ofert, zachowanie fulfillmentSellerId i mechanikę nadpisywania prowizji, tak aby Twoje zespoły inżynieryjne i produktowe mogły precyzyjnie wycenić zakres prac, zanim powstanie choćby jedna linia kodu.

TL;DR: Co wiedzieć przed wyceną wdrożenia marketplace'u VTEX

Wdrożenia marketplace'u VTEX najczęściej kończą się niepowodzeniem w dwóch punktach konfiguracyjnych, a nie na poziomie architektury. fulfillmentSellerId jest ustawiany niepoprawnie, gdy sprzedawcy pobierają SKU z różnych kont, a reguły autoApprove pozostają na domyślnych wartościach, które albo blokują każdą ofertę, albo zatwierdzają dane katalogu psujące doświadczenie klienta. Zanim zajmiesz się czymkolwiek innym, nastaw te dwie opcje prawidłowo, właściwa konfiguracja to fundament sprawnego wdrożenia.

W projektach, które wycenialiśmy i budowaliśmy na VTEX, nasz zespół konfigurował pipeline'y onboardingu sprzedawców, nadpisania prowizji na poziomie kategorii oraz reguły podziału płatności w wdrożeniach marketplace'ów detalicznych i B2B, co daje nam bezpośrednie dane o tym, gdzie koncentruje się nakład pracy inżynierów. Architektura platformy VTEX natywnie obsługuje pełny model multi-vendor, jednak różnica między działającym demo a gotowym do produkcji środowiskiem operatora marketplace'u jest większa, niż większość dokumentów wycenowych przyznaje.

Kluczowe fakty przed wyceną:

• Seller Portal to hostowana przestrzeń robocza, w której sprzedawcy konfigurują produkty, ceny, inwentarz, logistykę i płatności. Możesz ją obsługiwać przez VTEX Admin UI lub w całości przez REST API w przypadku niestandardowych przepływów onboardingu.
• Podzielone płatności obliczają prowizje automatycznie przy kasie; VTEX obsługuje struktury prowizji procentowych, stałych, warstwowych i specyficznych dla kategorii, osobno dla każdego sprzedawcy.
• Reguły autoApprove decydują, czy sugestie ofert trafiają od razu na żywo, czy do kolejki ręcznej weryfikacji. Błędna konfiguracja to najszybszy sposób na skażenie katalogu.
• fulfillmentSellerId identyfikuje osobę fizycznie realizującą zamówienie; kluczowe, gdy sprzedawca oferuje SKU pozyskane z innego konta sprzedawcy.
• Rozliczenia opierają się na podziale przychodów, a nie na stałej miesięcznej opłacie. Sprzedawcy spoza VTEX mają inną strukturę stawek niż sprzedawcy natywni dla VTEX, asymetria, która wpływa na Twój model komercyjny.

Ten przewodnik omawia architekturę marketplace'u VTEX, sekwencję onboardingu sprzedawcy (ścieżki UI i API), konfigurację prowizji, mechanikę podziału płatności oraz decyzję logistyczną dotyczącą realizacji przez sprzedawcę lub przez marketplace, konkretną warstwę potrzebną do precyzyjnego określenia zakresu budowy.

Architektura marketplace'u VTEX: model dwustronny

Konto operatora marketplace'u stanowi strukturalne centrum każdego wdrożenia VTEX Commerce Platform: to ono jest właścicielem definicji katalogu, przepływu przy kasie i logiki podziału płatności. Sprzedawcy wystawiają oferty względem tego katalogu, nigdy nie są właścicielami samego rekordu produktu. To rozróżnienie ma większe znaczenie, niż mogłoby się wydawać, i kształtuje każdą dalszą decyzję integracyjną.

Aby zrozumieć, jak działa hierarchia kont, warto przyjrzeć się następującej strukturze. Operator marketplace'u zarządza jedną lub kilkoma konfiguracjami kanałów sprzedaży, z których każda może udostępniać inny podzbiór katalogu, reguły cenowe lub storefront. Zewnętrzni sprzedawcy łączą się z konkretnym kanałem sprzedaży, a nie bezpośrednio z kontem marketplace'u.

Gdy sprzedawca wysyła ofertę, czyli cenę, ilość w magazynie i zobowiązanie logistyczne powiązane z istniejącym SKU, oferta ta przechodzi przez pipeline zarządzania sugestiami ofert, zanim stanie się możliwa do zakupu. Żadna informacja zapisana przez sprzedawcę nie trafia do kanonicznego rekordu produktu, dopóki marketplace jej nie zatwierdzi.

Dane przepływają w jednym kierunku przy tworzeniu oferty i w przeciwnym przy realizacji zamówienia. Sprzedawca tworzy ofertę → marketplace ocenia i zatwierdza → oferta pojawia się na storefront → klient składa zamówienie → zamówienie trafia do odpowiedniego konta sprzedawcy za pośrednictwem routingu zarządzania zamówieniami VTEX. Pole fulfillmentSellerId w linii zamówienia identyfikuje osobę faktycznie wysyłającą towar, różni się od konta sprzedającego, gdy sprzedawca pozyskuje towar z magazynu innego sprzedawcy lub gdy marketplace przejmuje realizację.

Realizacja przez sprzedawcę to domyślne założenie VTEX: sprzedawcy zarządzają własną strategią wysyłki, umowami z przewoźnikami i definicjami SLA wewnątrz Seller Portal. Realizacja przez marketplace odwraca ten model: logistyka operatora obsługuje fizyczną wysyłkę, a sprzedawcy jedynie potwierdzają dostępność towaru. Większość wdrożeń w średnim segmencie, które wycenialiśmy, zaczyna od realizacji przez sprzedawcę ze względu na prostotę, a następnie dodaje tory realizacji przez marketplace dla kategorii sprzedawców o dużym wolumenie lub o strategicznym znaczeniu, gdzie operator chce ściślejszej kontroli SLA.

W przypadku integracji zewnętrznych sprzedawców, czyli tych, którzy nie są jeszcze na platformie VTEX, obszar architektury jest szerszy. Ich systemy muszą łączyć się przez REST API, aby synchronizować inwentarz, odbierać powiadomienia o zamówieniach i potwierdzać zdarzenia wysyłki. Pełen protokół definiuje dokumentacja integracji marketplace'u VTEX. Sprzedawcy spoza VTEX podlegają też asymetrycznemu rozliczeniu: stawka platformy jest pobierana wyłącznie od operatora marketplace'u, a nie dzielona ze sprzedawcą, inaczej niż w przypadku sprzedawców natywnych dla VTEX, gdzie koszty są dzielone po obu stronach. Ta asymetria wpływa na to, jak operatorzy kształtują warunki handlowe z zewnętrznymi partnerami.

Szerszy kontekst architektury kont VTEX oraz obsługi przez platformę topologii multi-tenant SaaS znajdziesz w naszym przewodniku po platformie VTEX. Mechanika katalogu i danych produktowych, szczególnie istotna, gdy sprzedawcy potrzebują czystych, znormalizowanych informacji o produktach, zanim ich oferty będą mogły dopasować SKU, jest opisana w przewodniku po integracji PIM z VTEX.

Workflow onboardingu sprzedawcy: od zaproszenia do pierwszego zamówienia

Workflow onboardingu VTEX Seller Portal obejmuje siedem odrębnych etapów: od pierwszego kontaktu do realizacji zamówienia. Każdy etap ma jasno określonego właściciela, operatora marketplace'u lub sprzedawcę, oraz dedykowany endpoint API, jeśli chcesz całkowicie pominąć UI.

Etap 1: Zaproszenie. Operator marketplace'u wysyła zaproszenie na adres e-mail sprzedawcy przez VTEX Admin lub endpoint `POST /api/seller-register/pvt/sellers` (VTEX Help Center, Seller Portal: Getting started for the marketplace). W przypadku programów onboardingu dużej liczby sprzedawców korzystaj ze ścieżki API. Nasz zespół przygotowywał skrypty masowych zaproszeń dla klientów wprowadzających ponad 200 sprzedawców na nowy marketplace w jednym oknie uruchomienia, zadanie, które przez UI zajęłoby tygodnie.

Etap 2: Akceptacja. Sprzedawca otrzymuje e-mail, tworzy lub łączy swoje konto VTEX i akceptuje warunki. Sprzedawcy spoza VTEX (nieposiadający istniejącego sklepu VTEX) przechodzą tu pełne tworzenie konta, to miejsce, gdzie ścieżka UI i API rozchodzą się najbardziej. Marketplace chcący zapewnić onboarding w white-label może przez API utworzyć konto Seller Portal w imieniu sprzedawcy, a następnie bezpośrednio przekazać mu dane dostępowe.

Etap 3, Aktywacja. Operator marketplace aktywuje konto sprzedawcy. Do momentu aktywacji sprzedawca nie może niczego konfigurować. Aktywacja ustawia również fulfillmentSellerId sprzedawcy – identyfikator, który będzie oznaczał każdą linię zamówienia realizowaną przez tego sprzedawcę. Ma to znaczenie, gdy sprzedawca pozyskuje SKU od podmiotów trzecich.

Etap 4, Konfiguracja. Sprzedawca konfiguruje zasady cenowe, feedy inwentaryzacyjne, logistykę (realizacja przez sprzedawcę lub przez marketplace) oraz dane płatnicze w Seller Portal. W projektach, które wycenialiśmy dla branży modowej i elektronicznej, ten etap konsekwentnie zajmuje najwięcej czasu – zazwyczaj od pięciu do dziesięciu dni roboczych dla sprzedawców bez gotowego feedu produktowego. Kluczowe jest tu czyste dane katalogowe; wymagania dotyczące danych upstream znajdziesz w naszym przewodniku po integracji VTEX PIM.

Etap 5, Zgłoszenie oferty. Sprzedawcy zgłaszają oferty do katalogu marketplace za pomocą interfejsu zarządzania sugestiami ofert lub endpointu `POST /api/offer-manager/pvt/seller/{sellerId}/offer`. Oferta mapuje SKU sprzedawcy na rekord katalogu marketplace i zawiera informacje o cenie oraz stanie magazynowym. Cykl życia sugestii oferty obejmuje trzy stany: oczekującą, zatwierdzoną i odrzuconą – a operator marketplace kontroluje przejścia między nimi.

Etap 6, Zatwierdzenie oferty. To właśnie tutaj reguły autoApprove decydują o obciążeniu operacyjnym. Gdy autoApprove jest włączone na poziomie konta lub kategorii, oferty spełniające z góry zdefiniowane kryteria są zatwierdzane automatycznie – bez ręcznej weryfikacji. W praktyce nasz zespół konfigurował autoApprove dla kategorii towarowych (artykuły konsumpcyjne, akcesoria), wyłączając je dla kategorii o wysokiej wartości lub regulowanych (elektronika, suplementy), gdzie ręczny krok weryfikacji wychwytuje anomalie cenowe zanim dotrą do klienta.

Etap 7, Pierwsze zamówienie na żywo. Gdy co najmniej jedna oferta zostanie zatwierdzona, sprzedawca jest aktywny. Marketplace kieruje linie zamówień do sprzedawcy, przetwarzanie płatności podzielonych nalicza uzgodnioną prowizję, a sprzedawca zarządza realizacją z poziomu widoku zarządzania zamówieniami w Seller Portal.

API kontra UI: ścieżka przez UI sprawdza się w marketplace'ach onboardujących sprzedawców pojedynczo, przy dostępności pracowników operacyjnych; ścieżka przez API jest konieczna, gdy potrzebujesz własnego brandingu, masowego onboardingu lub programatycznej logiki autoApprove powiązanej z własnymi danymi oceny sprzedawców.

Onboarding przez UI kontra onboarding przez API: Kiedy wybrać którą ścieżkę

Integracja zewnętrznych sprzedawców przez API skaluje się lepiej; onboarding przez VTEX Seller Portal UI pozwala szybciej uruchomić pierwszych sprzedawców. Wybór zależy od wolumenu sprzedawców i poziomu kontroli, której potrzebujesz nad procesem rejestracji.

Onboarding przez UI (VTEX Admin + Seller Portal) sprawdza się, gdy uruchamiasz marketplace z wyselekcjonowaną grupą sprzedawców – powiedzmy, poniżej 50 – a Twój zespół chce ręcznie konfigurować każde konto, weryfikować zgłoszenia katalogowe przez wbudowany interfejs zarządzania ofertami i unikać budowania własnego middleware. Seller Portal prowadzi sprzedawców przez wprowadzanie danych produktowych, konfigurację cen, inwentaryzacji i logistyki – bez nakładu pracy inżynierów po stronie marketplace. W projektach, które wycenialiśmy dla mid-marketowych retailerów wchodzących w commerce marketplace, onboarding przez UI pozwala przeprowadzić sprzedawcę od zaproszenia do pierwszego zamówienia na żywo w ciągu dwóch do pięciu dni roboczych – zakładając czyste dane produktowe.

Onboarding przez API ma sens, gdy wolumen sprzedawców, wymagania automatyzacji lub własny UX rejestracji wykraczają poza możliwości interfejsu Admin. Endpoint `POST /api/seller-register/pvt/sellers` pozwala programatycznie tworzyć konta Seller Portal – przydatne, gdy chcesz wstępnie wypełniać dane sprzedawcy z zewnętrznego CRM, uruchamiać onboarding z poziomu własnej platformy lub budować white-labelowany flow nieujawniający brandingu VTEX. Nasz zespół konfigurował ścieżki API dla operatorów marketplace realizujących szybkie pozyskiwanie sprzedawców; nakład pracy inżynierskiej wynosi od trzech do sześciu tygodni, w zależności od złożoności logiki walidacji wokół kroków rejestracji sprzedawcy i zarządzania sugestiami ofert.

Zarządzanie ofertami i katalogiem: Sugestie, dopasowanie i autoApprove

Zarządzanie sugestiami ofert w VTEX Commerce Platform przebiega według zdefiniowanego cyklu życia: sprzedawca zgłasza ofertę, marketplace ją ręcznie weryfikuje lub przetwarza automatycznie za pomocą reguł autoApprove, a widoczne dla klientów stają się tylko zatwierdzone oferty. Znajomość miejsc, w których ten cykl może się załamać, jest bardziej wartościowa niż znajomość samej szczęśliwej ścieżki.

Dopasowanie katalogu a tworzenie nowych produktów

Gdy sprzedawca zgłasza ofertę dla SKU, który już istnieje w katalogu marketplace, VTEX próbuje dopasować go po EAN lub ID referencyjnym. Dopasowana oferta dziedziczy dane produktowe marketplace – tytuł, zdjęcia, opis – a sprzedawca uzupełnia cenę i stan magazynowy. To najczystsza ścieżka: marketplace kontroluje katalog widoczny dla klientów, a sprzedawcy konkurują ceną i dostępnością.

Jeśli dopasowanie nie istnieje, sprzedawca może zgłosić sugestię nowego produktu. Zespół marketplace weryfikuje wówczas przychodzące dane – tytuł, przypisanie kategorii, zdjęcia, atrybuty – zanim zatwierdzi produkt do katalogu. W naszym doświadczeniu przy wycenie projektów VTEX, to właśnie ta kolejka weryfikacji jest miejscem, gdzie jakość katalogu najszybciej się pogarsza. Sprzedawcy zgłaszają produkty z brakującymi atrybutami, błędnym przypisaniem kategorii lub zdjęciami w niskiej rozdzielczości. Bez zdefiniowanego SLA po stronie weryfikacji kolejka rośnie. Zalecamy konfigurację walidacji wymaganych atrybutów na poziomie kategorii zanim oferty trafią do kolejki zatwierdzania – zamiast ręcznego wychwytywania błędów po fakcie.

Logika reguł autoApprove i jej ryzyka

Reguły autoApprove pozwalają marketplace konfigurować warunki, w których aktualizacje ofert – zmiany cen, aktualizacje stanów magazynowych lub nowe oferty od zaufanych sprzedawców – są akceptowane bez ręcznej weryfikacji. Zgodnie z dokumentacją konfiguracji marketplace VTEX, autoApprove można zawęzić do konkretnych sprzedawców, kategorii lub typów ofert.

Nadmiernie permisywne reguły autoApprove stanowią realne ryzyko operacyjne. Reguła automatycznie zatwierdzająca wszystkie aktualizacje cen od wszystkich sprzedawców może na przykład ujawnić klientom błąd cenowy sprzedawcy – pomyłkę w miejscu dziesiętnym, która wycenia produkt za 500 € na 5 € – zanim ktokolwiek to zauważy. W projektach, które wycenialiśmy, konfigurujemy autoApprove wąsko: wyłącznie dla zaufanych sprzedawców, wyłącznie dla aktualizacji stanów magazynowych, a zmiany cen zawsze wymagają kroku weryfikacji lub reguły walidacji ceny minimalnej. Nakład pracy inżynierskiej przy dodaniu tego zabezpieczenia jest niewielki; koszt operacyjny incydentu cenowego na żywo – już nie.

Struktury prowizji: Procentowa, stała, warstwowa i nadpisania kategorii

Model rozliczeń revenue-share w VTEX nalicza prowizje automatycznie podczas przetwarzania płatności podzielonych – bez osobnego kroku fakturowania. Operator marketplace konfiguruje reguły prowizji w ustawieniach przed uruchomieniem sprzedawców, a VTEX oblicza podział stawki w momencie transakcji.

Dwa typy prowizji, nie jeden

Każda konfiguracja sprzedawcy zawiera dwa niezależne pola prowizji: prowizję od produktu (procent ceny sprzedaży towaru) oraz prowizję od dostawy (procent opłaty za wysyłkę pobranej od klienta). Obie są obliczane i rozliczane oddzielnie podczas rozliczania płatności. Pozostawienie prowizji od dostawy na poziomie zera to częsty błąd przy pierwszej konfiguracji. Może kosztować operatorów marketplace'u realny przychód w kanałach o dużym wolumenie i niskiej średniej wartości zamówienia, gdzie opłaty za wysyłkę stanowią znaczną część wartości koszyka, zwłaszcza przy towarach codziennego użytku z niskimi marżami.

Modele prowizji obsługiwane przez VTEX

Reguły prowizji konfiguruje się dla sprzedawcy w obrębie wszystkich kategorii lub dla sprzedawcy w konkretnej kategorii. W projektach realizowanych dla operatorów marketplace'u działających w wielu branżach, ta możliwość nadpisania konsekwentnie obniża nakład pracy przy konfiguracji, gdy jeden sprzedawca obejmuje zarówno produkty wysokomarżowe, jak i niskomarżowe, na przykład kosmetyki i produkty do pielęgnacji obok elektroniki użytkowej.

Dokumentacja VTEX nie publikuje twardego limitu liczby reguł nadpisania dla konkretnej kategorii, które można skonfigurować na koncie sprzedawcy. Jeśli Twój use case obejmuje wyjątkowo rozbudowaną taksonomię kategorii, potwierdź aktualne limity platformy bezpośrednio z zespołem konta VTEX, zanim sfinalizujesz architekturę prowizji.

W przypadku sprzedawców spoza VTEX, skontraktowana stawka prowizji obciąża wyłącznie operatora marketplace'u. W przypadku sprzedawców natywnych VTEX jest ona dzielona między sprzedawcę a marketplace, to asymetria rozliczeniowa, którą warto poruszyć na wczesnym etapie negocjacji handlowych ze sprzedawcami już korzystającymi z VTEX do prowadzenia własnego sklepu.

Split payments w VTEX: jak naprawdę działa przepływ płatności

Przetwarzanie płatności podzielonych (split payments) w VTEX Commerce Platform uruchamia się w momencie transakcji, a nie po rozliczeniu. Gdy klient finalizuje zamówienie, VTEX oblicza potrącenie prowizji marketplace'u w czasie rzeczywistym i automatycznie przekazuje kwotę netto do sprzedawcy, bez oddzielnego fakturowania i bez ręcznego kroku uzgadniania.

Gdzie faktycznie następuje potrącenie prowizji

Podział następuje podczas przechwycenia płatności, zanim środki zostaną przekierowane. VTEX odczytuje skonfigurowane ustawienia prowizji dla danego sprzedawcy i kategorii, potrąca stawkę marketplace'u i rejestruje należność netto sprzedawcy w tym samym rekordzie transakcji. Prowizje od produktów i prowizje od dostawy są potrącane niezależnie, a podział kosztów wysyłki odbywa się zgodnie ze stawką prowizji od dostawy skonfigurowaną dla danego sprzedawcy, która może różnić się od stawki produktowej.

Różnica w rozliczaniu sprzedawców spoza VTEX, często źle rozumiana

To właśnie tutaj wiele zespołów błędnie definiuje architekturę. W przypadku sprzedawców natywnych VTEX, tych, którzy prowadzą własne konto VTEX, skontraktowana stawka prowizji obciąża zarówno sprzedawcę, jak i marketplace, ponieważ VTEX pozostaje w bezpośredniej relacji handlowej z każdą ze stron. W przypadku zewnętrznych sprzedawców (konta spoza VTEX, wdrożone za pośrednictwem Seller Portal) stawka obciąża wyłącznie operatora marketplace'u. Marketplace egzekwuje wówczas własne warunki handlowe ze sprzedawcami poza warstwą rozliczeniową VTEX.

W praktyce: jeśli Twój mix sprzedawców to głównie firmy spoza VTEX, niezależne marki, regionalni dostawcy, dropshipperzy sprzedający towary fizyczne lub oferty usługowe w wielu kanałach, Twoja faktura VTEX Commerce Platform odzwierciedla pełną opłatę opartą na GMV. To Ty ponosisz ten koszt i odzyskujesz go poprzez stawki prowizji skonfigurowane dla każdego sprzedawcy. Błąd w ustawieniach prowizji generuje strukturalną lukę marżową, a nie błąd zaokrąglenia.

Częsty schemat błędu: marketplace z większościowym udziałem sprzedawców spoza VTEX pozostawia stawkę prowizji od dostawy niedopasowaną do rzeczywistych kosztów przewoźnika dla poszczególnych poziomów sprzedawców, a powstały niedobór marży jest błędnie przypisywany kosztom logistyki, zamiast prześledzić go do konfiguracji prowizji. Naprawa leży wyłącznie w ustawieniach prowizji i nie wymaga żadnych zmian w warstwie integracji płatności, wystarczy skorygować stawkę prowizji od dostawy dla danego poziomu sprzedawcy.

Dla zespołów łączących sprzedawców programowo za pomocą VTEX Marketplace APIs, dane o podziale są dostępne na poziomie zamówienia. Dzięki temu można łatwo przesyłać dane o przychodach poszczególnych sprzedawców do zewnętrznych systemów BI lub finansowych bez potrzeby tworzenia odrębnego eksportu uzgodnieniowego.

Modele realizacji zamówień: co kontroluje fulfillmentSellerId i jak podjąć decyzję

Pole fulfillmentSellerId identyfikuje, kto fizycznie wysyła zamówienie, jego błędne ustawienie po cichu przekierowuje realizację do niewłaściwej strony. Domyślna architektura VTEX zakłada, że sprzedawca wskazany w zamówieniu jest również sprzedawcą je realizującym, ale to założenie przestaje działać, gdy sprzedawca pobiera SKU od innego sprzedawcy albo marketplace prowadzi własny magazyn.

Jak fulfillmentSellerId działa w praktyce

Gdy sprzedawca sprzedaje produkt z własnego asortymentu, fulfillmentSellerId jest równe identyfikatorowi konta tego sprzedawcy. Gdy marketplace chce realizować zamówienie w imieniu sprzedawcy, centralizując logistykę na potrzeby kontroli jakości lub gwarancji SLA, fulfillmentSellerId zostaje ustawione na identyfikator własnego sprzedawcy marketplace'u. VTEX przekierowuje instrukcję kompletacji i wysyłki zgodnie z tym ustawieniem, a podział przychodów nadal uznaje konto sprzedawcy źródłowego. To właśnie to pole umożliwia dropshipping realizowany przez marketplace bez konieczności przebudowy katalogu ani architektury zarządzania zamówieniami.

Wybór odpowiedniego modelu dla Twojego kontekstu

Decyzja nie jest zero-jedynkowa. VTEX natywnie obsługuje trzy wzorce, które mogą współistnieć w ramach Twojego miksu sprzedawców:

Dropshipping naturalnie wpisuje się w model realizacji przez sprzedawcę: sprzedawca nie trzyma towaru na magazynie, fulfillmentSellerId wskazuje na jego konto, a on sam przekazuje zamówienia do swojego dostawcy. Wysyłka ze sklepu i click-and-collect wymagają skonfigurowania ustawień logistycznych na poziomie fizycznej lokalizacji sprzedawcy w platformie, a nie tylko na poziomie konta.

Częsty wzorzec dla marketplace'ów wielokategoriowych: przypisanie statusu realizacji przez marketplace nowym sprzedawcom oraz kategoriom o wysokim wskaźniku zwrotów (odzież, obuwie), przy jednoczesnym zachowaniu przez sprawdzonych sprzedawców z partnerami 3PL statusu realizacji przez sprzedawcę. Tę logikę routingu warto zdefiniować per kategoria na wczesnym etapie, jej późniejsze wdrożenie po uruchomieniu sprzedawców znacząco zwiększa nakład pracy koordynacyjnej.

VTEX vs. Mirakl vs. Marketplacer: porównanie według kluczowych wymiarów

VTEX Commerce Platform, Mirakl i Marketplacer obsługują ten sam scenariusz wielu sprzedawców, lecz przyjmują fundamentalnie różne założenia architektoniczne, a te założenia decydują o koszcie integracji, czasie do uruchomienia pierwszego sprzedawcy oraz o kontroli operatora w długim terminie.

Różnica w TCO ma charakter strukturalny. Rozliczenia VTEX są uzależnione od GMV, operator marketplace'u płaci więcej wraz ze wzrostem platformy, ale płaci mniej, zanim ta skala zostanie osiągnięta. Model licencyjny Mirakl generuje koszty z góry, niezależnie od liczby sprzedawców czy wolumenu transakcji.

Wyraźną przewagą VTEX jest architektura: storefront, zarządzanie katalogiem, przetwarzanie płatności podzielonych i onboarding zewnętrznych sprzedawców, wszystko w jednej platformie. Siła Mirakl leży natomiast po przeciwnej stronie: integruje się płynnie z istniejącym stosem e-commerce, którego operator nie chce zastępować. Jeśli operator korzysta już z Salesforce Commerce Cloud lub SAP Commerce i nie planuje migracji platformy, Mirakl jest ścieżką o mniejszym poziomie zakłóceń.

W projektach, które wycenialiśmy, decyzja najczęściej sprowadza się do jednego pytania: czy operator chce, żeby jedna platforma obsługiwała zarówno e-commerce, jak i marketplace, czy woli dodać warstwę marketplace'ową na szczycie istniejącego systemu w modelu best-of-breed? VTEX wygrywa w pierwszym scenariuszu, Mirakl, w drugim. Jeśli chcesz dokładniej poznać szerszą architekturę e-commerce VTEX przed podjęciem tej decyzji, zajrzyj do naszego przewodnika po platformie VTEX.

Najczęściej zadawane pytania dotyczące marketplace VTEX

Lista kontrolna przed wdrożeniem: Decyzje do podjęcia przed rozpoczęciem developmentu

Podejmij te sześć decyzji, zanim Twój zespół developerski napisze choćby jedną linię kodu integracyjnego. Powrót do nich w trakcie budowania kosztuje tygodnie; architektura platformy VTEX sprawia, że kilka z nich jest naprawdę trudnych do odwrócenia.

1. Struktura typów sprzedawców. Sklasyfikuj swoją bazę sprzedawców: konta natywne dla VTEX vs. zewnętrzni sprzedawcy korzystający z Seller Portal. To determinuje asymetrię stawek prowizji, zewnętrzni sprzedawcy spoza VTEX generują prowizję obciążającą wyłącznie operatora marketplace, podczas gdy sprzedawcy natywni dzielą ją między siebie. Określ ten stosunek jak najwcześniej, bo wpływa na model podziału przychodów i projekcje rozliczeniowe.

1. Ścieżka onboardingu: UI vs. API. Panel administracyjny VTEX obsługuje standardowe przepływy zapraszania i aktywowania sprzedawców. Jeśli chcesz programowo tworzyć konta w Seller Portal w imieniu sprzedawców, co jest typowe przy onboardingu partnerów enterprise lub dużych wolumenach, zaplanuj ścieżkę REST API od pierwszego dnia. W projektach, które wycenialiśmy, przejście z onboardingu opartego na UI na podejście API w trakcie budowania dodawało od trzech do czterech tygodni pracy inżynierskiej.

1. Struktura prowizji i nadpisania per kategoria. Zdecyduj, czy potrzebujesz logiki prowizji opartej na stałym procencie, stałej opłacie, progach czy nadpisaniach per kategoria. VTEX oblicza prowizje od produktów i prowizje od wysyłki oddzielnie podczas przetwarzania płatności podzielonych; konfiguruj je per sprzedawca lub per pojedynczą kategorię. Pozostawienie tego punktu nieokreślonego sprawia, że deweloperzy konfigurują wartość domyślną, a następnie pod presją czasu doimplementowują wyjątki.

1. Własność fulfillmentu i pole fulfillmentSellerId. Ustal domyślne podejście: fulfillment po stronie sprzedawcy, po stronie marketplace czy model hybrydowy. Pole fulfillmentSellerId identyfikuje, kto fizycznie wysyła każde zamówienie: ma to kluczowe znaczenie od razu, gdy sprzedawcy wystawiają SKU pozyskane od innych sprzedawców. Ustalenie zasad ship-from-store, click-and-collect i dropshippingu przed rozpoczęciem budowania pozwala uniknąć błędnie zmapowanych przepływów logistycznych w zarządzaniu zamówieniami.

1. Tolerancja ryzyka dla autoApprove. Operator marketplace ustawia reguły autoApprove per sprzedawca lub per kategoria, kontrolując, czy sugestie ofert trafiają na żywo bez ręcznej weryfikacji. Sprzedawcy wysoko zaufani i z weryfikowanym asortymentem mogą mieć włączone autoApprove; nowi lub zewnętrzni sprzedawcy zazwyczaj wymagają weryfikacji przez człowieka. Zdefiniuj macierz zatwierdzeń, wraz z regułami eskalacji dla anomalii cenowych, zanim zbudujesz przepływ zarządzania sugestiami ofert.

1. Konfiguracja kanałów sprzedaży i architektura storefront. Każdy marketplace na VTEX wymaga dedykowanego konta kanału sprzedaży. Zdecyduj z góry, czy prowadzisz jeden storefront skierowany do klientów, architekturę white-label dla sub-operatorów, czy headless frontend konsumujący VTEX API. To determinuje sposób partycjonowania danych katalogu, cen i promocji między kontami, a restrukturyzacja po podłączeniu sprzedawców jest zdecydowanie trudniejsza.

Decyzje dotyczące katalogu i danych produktowych, które zasilają kroki 1-6, szczegółowo opisuje mechanikę modelu danych przewodnik po integracji VTEX PIM (VTEX Back office integration guide (ERP/PIM/WMS)).

Gotowy do wyceny swojego marketplace na VTEX?

Jeśli lista kontrolna z poprzedniej sekcji ujawniła decyzje, których jeszcze nie podjąłeś, to właśnie ten moment, by zaangażować partnera inżynierskiego, który konfigurował VTEX Commerce Platform dla operatorów marketplace, zanim, nie po pierwszym sprincie.

Nasz zespół wyceniał i budował projekty commerce z wieloma sprzedawcami w różnych branżach, poruszając się po specyfice architektury platformy VTEX: onboarding sprzedawców przez API vs. UI, logika przetwarzania płatności podzielonych oraz wybór między fulfillmentem po stronie sprzedawcy a po stronie marketplace. Widzieliśmy, gdzie niska jakość danych zewnętrznych sprzedawców niszczy integralność katalogu i gdzie decyzje o konfiguracji prowizji podjęte zbyt późno stają się kosztowne do zmiany. Jeśli analizujesz VTEX i chcesz rzetelnej oceny architektury, harmonogramu i rzeczywistego nakładu pracy inżynierskiej, zbuduj swoją platformę commerce razem z nami.