Marketplace z PayPal Multiparty: jak działa Boutique Hanka

Boutique Hanka to francuski marketplace ze świecami, eliksirami, przedmiotami do medytacji i rzeźbami z brązu, w którym sześciu sprzedawców handluje razem w jednym sklepie. Działa na CS-Cart Multi-Vendor, po francusku i w euro, a kupujący często bierze do koszyka rzeczy od kilku sprzedawców naraz. Współpracujemy z jego właścicielem od maja 2025 roku. Ten tekst opisuje, co trzeba było dobudować i poprawić, żeby taki koszyk był wygodny dla kupującego, bezpieczny przy płatności i odporny na szczyty ruchu.

Koszyk wielu sprzedawców to tu codzienność

W wielu marketplace kupujący wybiera jeden produkt od jednego sprzedawcy. W Boutique Hanka jest inaczej: w okresie od sierpnia do września 2026 roku prawie połowa zamówień sprzedawców pochodziła z koszyków, w których byli też inni twórcy. Każdy taki koszyk Multi-Vendor dzieli na osobne zamówienia sprzedawców, a każde z nich ma własną dostawę, własny status i własną część płatności. To wygodne dla rozliczeń, ale stawia przed sklepem dwa pytania: ile kupujący zapłaci za wysyłkę i jak podzielić jedną płatność między kilku odbiorców.

Wspólna dostawa sprzedawców z jednego miejsca

Pierwsze zlecenie przyszło w maju 2025 roku przez wiadomości na CS-Cart Marketplace. Część sprzedawców Boutique Hanka pracuje pod jednym adresem i wysyła zamówienia razem, jedną paczką. Standardowy Multi-Vendor nie ma tej wiedzy i liczy dostawę u każdego sprzedawcy osobno, więc kupujący, który wziął świecę od jednego twórcy i eliksir od drugiego, płacił za przesyłkę dwa razy, choć dostawał jedną paczkę. Sprzedawcy niezależni, wysyłający z własnego warsztatu, mieli przy tym zachować własną opłatę.

Na tę potrzebę napisaliśmy dodatek Łączenie kosztów dostawy sprzedawców. Operator łączy w panelu sprzedawców w grupy według miejsca nadania, a w koszyku dostawę płaci się raz na grupę. Wersję testową z sześcioma sprzedawcami i francuskim interfejsem udostępniliśmy na początku czerwca 2025 roku. Test od kasy do zamówień sprzedawców pokazał, że po podziale koszyka opłata potrafiła wrócić do pozostałych członków grupy, więc poprawiliśmy jej rozkład na zamówienia sprzedawców i dodaliśmy ustawienie, które wskazuje, przy jakich metodach dostawy grupowanie działa. Na początku lipca dodatek trafił na produkcję, a jesienią 2026 roku przygotowaliśmy jego wersję dla PHP 8.2, którą operator sprawdził na kopii sklepu.

PayPal Multiparty, czyli jedna płatność dla kilku sprzedawców

We wrześniu 2025 roku właściciel chciał, żeby płatność za koszyk trafiała prosto do sprzedawców, bez przechodzenia przez jego konto. Multi-Vendor ma do tego PayPal Commerce Platform w trybie Multiparty: kupujący płaci raz, a PayPal dzieli kwotę między sprzedawców, z których każdy podłącza w swoim profilu własne konto PayPal. Zaproponowaliśmy też Stripe jako alternatywę, ale klient wolał zostać przy PayPalu, z którego korzystał od lat.

Najtrudniejsza część nie była techniczna. Formularz partnera PayPala przez kilka tygodni nie przynosił odpowiedzi, a po dotarciu do opiekuna okazało się, że platforma potrzebuje osobnego konta firmowego w roli partnera marketplace. Nowe konto przeszło weryfikację pod koniec października, a interfejs API zaczął przyjmować płatności dopiero wtedy, gdy PayPal skonfigurował po swojej stronie opłatę platformy. Komunikację z PayPalem prowadziliśmy w imieniu klienta. Na początku listopada 2025 roku sprzedawcy podłączyli swoje konta, a pierwsza płatność przeszła i została podzielona.

Jeśli planujesz podobny model, zarezerwuj na rejestrację w PayPalu więcej czasu niż na konfigurację sklepu. Inne sposoby dzielenia płatności w marketplace porównujemy we wpisie o split payment.

Nowy sprzedawca rok później

Pod koniec października 2026 roku do sklepu dołączył szósty sprzedawca. W jego profilu zakładka PayPal pokazywała brak połączenia, ale bez przycisku, którym sprzedawca podłącza konto. Właściciel zauważył przy tym, że ten sam test połączenia z PayPalem działa z konsoli serwera, a ze sklepu już nie. Sprawdziliśmy to i okazało się, że problem jest szerszy niż jeden sprzedawca: od poprzedniego wieczoru sklep nie mógł połączyć się z żadną usługą zewnętrzną, ani z PayPalem, ani z ShipStation, ani z Google, więc od tej chwili nie przeszło żadne zamówienie.

Przyczyną była blokada bezpieczeństwa założona przez hosting na połączenia wychodzące sklepu. Po jej zdjęciu przycisk wrócił, nowy sprzedawca podłączył własne konto PayPal, a pierwszy koszyk z jego produktem został opłacony i podzielony między trzech sprzedawców. Dopilnowaliśmy też, żeby nowa firma nie podpięła się przez pomyłkę pod konto PayPal innego sprzedawcy prowadzonego przez tę samą osobę, bo sklep by to przyjął, a pieniądze obu firm trafiałyby na jedno konto.

Cztery poprawki kasy PayPal

We wrześniu 2026 roku operator zgłosił, że kupujący po zatwierdzeniu płatności w PayPalu zobaczył pustą stronę z odmową dostępu, a pieniądze nie zostały pobrane. Analiza pokazała, że to zachowanie samego dodatku PayPal w CS-Carcie, a nie konfiguracji sklepu, i że ten sam schemat występuje w najnowszej wersji. Znaleźliśmy trzy osobne błędy, a jeden z nich dotyczył wyłącznie koszyków wielu sprzedawców. Czwarta poprawka doszła na prośbę operatora i dotyczy komunikatów dla kupującego.

Pierwszy błąd dotyczył powtórnych kliknięć przycisku płatności. Każde kliknięcie zakłada nowe zamówienie, a skrypt kasy pamiętał tylko numer ostatniego. Gdy kupujący zatwierdził płatność rozpoczętą wcześniej, sklep porównywał ją z innym zamówieniem i odrzucał powrót bez pobrania pieniędzy. Po poprawce skrypt pamięta numer osobno dla każdej płatności, a serwer dalej sprawdza zgodność zamówienia z płatnością, tak jak wcześniej. Ta poprawka ma jeszcze dwie części: odrzucony powrót zostawia wpis w dzienniku zdarzeń sklepu, a płatność jest pobierana tylko raz, nawet gdy kupujący wróci do sklepu ponownie.

Drugi błąd pojawiał się, gdy przeglądarka wracała z PayPala dwa razy niemal w tej samej chwili. Drugi powrót dostawał od PayPala odpowiedź, że płatność już pobrano, a sklep traktował ją jak nieudaną płatność i wysyłał kupującemu wiadomość o niepowodzeniu. Teraz sklep w takiej sytuacji pyta PayPala o stan płatności i czeka na wynik pierwszego powrotu.

Trzeci był wyścigiem dwóch równoległych zdarzeń. Powrót kupującego ustawiał zamówieniu nadrzędnemu status otwarty i przepisywał go w pętli na zamówienia sprzedawców, a w tym samym czasie powiadomienie od PayPala oznaczało część z nich jako opłacone. Pętla, która odczytała statusy wcześniej, cofała opłacone zamówienia do statusu otwartego, więc sprzedawcy i kupujący dostawali sprzeczne wiadomości, a raporty pokazywały nieopłacone zamówienia. Poprawka sprawdza bieżący status przed każdą zmianą z powrotu PayPala i nie cofa zamówienia, które jest już opłacone.

Czwarta poprawka porządkuje komunikaty. Gdy przyciski PayPala się nie załadują albo zamówienia nie da się utworzyć, kupujący dostaje teraz komunikat. Wcześniej standardowy skrypt kasy część takich błędów przechwytywał po cichu, więc kupujący mógł nie zobaczyć żadnej informacji. Zwykłe płatności i ponowna płatność za nieudane zamówienie działają tak jak wcześniej.

Poprawki sprawdzaliśmy przed wdrożeniem na kopii sklepu z piaskownicą PayPala, od kilku kliknięć i zamknięcia okna po koszyk kilku sprzedawców i dwa powroty w tej samej sekundzie. Zmiany, które dało się umieścić poza plikami rdzenia, trafiły do osobnego dodatku sklepu, żeby przetrwały aktualizacje, a do pozostałych operator dostał instrukcję ponownego naniesienia. Wszystkie cztery poprawki działają na produkcji od października 2026 roku. W pierwszych dniach po ostatnim wdrożeniu sześć prawdziwych płatności zakończyło się pobraniem, a operator sprawdził w PayPalu, że wszystkie dwanaście części trafiło do sprzedawców.

Zdjęcia, które potrafiły zatrzymać sklep

Sprzedawcy Boutique Hanka fotografują swoje wyroby sami, a część zdjęć trafiała do sklepu prosto z aparatu, nawet po 25 megabajtów. We wrześniu 2026 roku, po wyczyszczeniu miniatur, sklep zaczął zwracać błędy, także w panelu. Hosting współdzielony nie nadążał z odtwarzaniem tysięcy miniatur naraz, a dodatek powiększania zdjęć przy kwadratowych miniaturach i niekwadratowych oryginałach budował obrazy w pełnym rozmiarze oryginału. Jeszcze tego samego wieczoru sklep wrócił do działania. Następnego dnia błędy wróciły, a po wyłączeniu powiększania sklep pracuje stabilnie.

Drugim problemem były białe ramki wokół zdjęć. Pojawiały się wtedy, gdy miniatura miała inne proporcje niż zdjęcie albo była większa niż oryginał, bo CS-Cart dopełnia brakujące miejsce białym tłem. Zmieniliśmy ustawienia miniatur i przebudowaliśmy je, więc ramki zniknęły na niemal wszystkich produktach, bez kadrowania i deformowania zdjęć, a siatkę kafelków na listach wyrównaliśmy stylem dodanym poza plikami motywu, żeby przetrwał jego aktualizację. Wynik sprawdziliśmy w trzech silnikach przeglądarek.

Pomiar i widoczność w Google

Właściciel uważał, że Google Analytics 4 jest zepsute, bo pokazuje mniej sprzedaży niż sklep. Okazało się, że działa poprawnie, ale liczy wyłącznie tych kupujących, którzy zgodzili się na pliki cookie, czyli mniej więcej połowę wartości sprzedaży. Wyjaśniliśmy też, skąd w Multi-Vendorze bierze się różnica między liczbą zamówień w bazie a liczbą transakcji, bo każde podejście do płatności i każdy sprzedawca w koszyku zakłada osobny wiersz zamówienia.

W tym samym zleceniu uruchomiliśmy automatyczne odświeżanie mapy witryny i pliku produktowego dla Google Merchant Center, a stare adresy bloga przekierowaliśmy na nowe. Zadania cykliczne napisaliśmy tak, żeby dało się je ustawić w panelu hostingu, który nie przyjmuje poleceń z parametrami.

Sklep gotowy na szczyt ruchu

Boutique Hanka raz w roku wieczorem wypuszcza kolekcję rzeźb z brązu, więc ruch i zakupy skupiają się w jednej godzinie. Przy jednej z premier hosting współdzielony przestał nadążać, a sklep działał z przerwami. Jeszcze tego samego wieczoru pomogliśmy zdiagnozować przyczynę. W 2026 roku przenieśliśmy bazę danych na osobną usługę, z wyższym limitem połączeń i nowszą wersją MySQL, bo dotychczasowa znikała z oferty hostingu. Sama migracja zamknęła sklep na około sześć minut, a porównanie wszystkich tabel przed i po przeniesieniu wyszło zgodne.

W tym samym miesiącu sklep przeszedł na PHP 8.2. Jedynym elementem, który blokował zmianę, był szablon faktury liczący sumy na sformatowanych kwotach, co nowsza wersja PHP traktuje jako błąd. Poprawiliśmy go tak, żeby faktury wyglądały i liczyły się dokładnie tak samo jak wcześniej. Przy okazji zaktualizowaliśmy integrację z ShipStation, przez którą sprzedawcy nadają paczki Colissimo. Przed aktualizacją przejrzeliśmy kod obu wersji, bo przy domyślnych ustawieniach nowa wersja zmieniłaby sposób eksportu zamówień jednego ze sprzedawców. Poprawiliśmy też kolejność zapisu w dodatku, tak żeby wiadomość o wysyłce zawsze zawierała numer przesyłki.

Co pracuje w sklepie

Boutique Hanka korzysta z edycji Multi-Vendor PLUS. Z naszych rozwiązań działa w nim dodatek Łączenie kosztów dostawy sprzedawców, a poprawka statusów zamówień, styl siatki produktów i zabezpieczenie integracji siedzą w osobnym dodatku sklepu, oddzielonym od plików rdzenia. Pozostałe poprawki PayPala są w plikach rdzeniowego dodatku, a operator ma instrukcję ich ponownego naniesienia po aktualizacji. Płatności obsługuje rdzeniowy PayPal Commerce Platform w trybie Multiparty, wysyłkę integracja z ShipStation, a wygląd motyw Syrup od ThemeHills. Od października 2026 roku zmiany testujemy najpierw na kopii sklepu z wyłączoną wysyłką maili, wyzerowanymi kluczami ShipStation i PayPalem w trybie testowym, a operator dostaje paczkę z opisem i instrukcją ponownego naniesienia po aktualizacji.

Czego uczy to wdrożenie

Multi-Vendor dzieli koszyk na zamówienia sprzedawców bardzo sprawnie, ale każde miejsce, w którym te zamówienia znów się spotykają, wymaga uwagi. Dotyczy to wspólnej wysyłki, jednej płatności dzielonej między sprzedawców i statusów, które zmienia jednocześnie kupujący i bramka płatnicza. Jeśli w Twoim marketplace koszyki z kilkoma sprzedawcami są częste, przetestuj właśnie te ścieżki, najlepiej na kopii sklepu z piaskownicą bramki, zanim zrobią to klienci.

Drugi wniosek dotyczy rejestracji w bramce. Model, w którym pieniądze trafiają prosto do sprzedawców, wymaga po stronie operatora konta partnera i weryfikacji, która trwa tygodniami. Trzeci dotyczy hostingu: sklep z dużymi zdjęciami i jednorazowymi szczytami ruchu szybko dochodzi do granic serwera współdzielonego, a objawy, takie jak błędy przy miniaturach czy brak połączenia z bramką, nie zawsze wskazują wprost na przyczynę. Więcej o modelach rozliczeń piszemy na stronie o płatnościach w marketplace, a pozostałe wdrożenia znajdziesz na liście realizacji.

Jeśli prowadzisz marketplace z koszykiem wielu sprzedawców albo planujesz podział płatności przez PayPal lub inną bramkę, napisz do nas. Sprawdzimy, jak Twój sklep zachowa się w tych sytuacjach.