Podział koszyka w platformie dla firm. Jak dzielić zamówienia, płatności, wypłaty i faktury?

Platforma dla firm z wieloma sprzedawcami wygląda prosto z perspektywy kupującego: wybieram produkty od trzech dostawców, klikam "zamów" i przechodzę przez jedną spójną ścieżkę zakupu. Operacyjnie to jednak kilka niezależnych transakcji: różne magazyny, terminy dostawy, stawki VAT, koszty transportu, progi rabatowe, limity kredytowe, faktury i polityki zwrotów.

Jeżeli platforma traktuje koszyk jak zwykłe zamówienie od jednego sprzedawcy, cały przychód trafia w jedno miejsce, a zespół finansowy ręcznie dzieli prowizje, noty, wypłaty i korekty. Jeżeli zmusisz kupującego do trzech osobnych płatności, poprawisz księgowość, ale pogorszysz doświadczenie zakupowe i zwiększysz liczbę porzuconych koszyków.

Dobry podział koszyka nie jest więc tylko integracją płatności. To model domenowy dla zamówień, rozliczeń, realizacji dostaw i kontroli ryzyka. Najpierw trzeba ustalić, kto jest sprzedawcą formalnym, kto wystawia fakturę, kto obsługuje spór płatniczy lub obciążenie zwrotne, kto odpowiada za dostawę i kiedy sprzedawca dostaje środki.

W rozmowach o platformach z wieloma sprzedawcami pojęcia "podział koszyka", "podział płatności" i "podział zamówienia" często są używane zamiennie. To niebezpieczne, bo każdy z tych obszarów ma inne konsekwencje techniczne, prawne i księgowe.

• Podział koszyka i doświadczenia kupującego: kupujący widzi jeden koszyk, ale pozycje są pogrupowane według sprzedawcy, magazynu, metody dostawy lub warunków handlowych.
• Podział zamówienia: po zatwierdzeniu powstają zamówienia sprzedawców, na przykład `ORD-1001-A`, `ORD-1001-B`, `ORD-1001-C`, z osobnymi statusami realizacji.
• Podzielona płatność: jedna autoryzacja lub jedna płatność finansuje wiele przelewów do sprzedawców, prowizję platformy i ewentualne koszty wspólne.
• Podział faktur i uzgodnienie rozliczeń: faktury, korekty, podatki, zwroty, spory płatnicze i wypłaty muszą dać się uzgodnić w systemie finansowo-magazynowym albo księgowości.

Stripe Connect opisuje dwa ważne modele. W pierwszym płatność jest kierowana do jednego głównego sprzedawcy, a platforma pobiera swoją prowizję. W drugim platforma najpierw pobiera środki, a dopiero później przekazuje odpowiednie kwoty do wielu połączonych kont sprzedawców. Stripe wprost wskazuje, że przy takim modelu zwykle potrzebujesz księgi rozliczeń, żeby wiedzieć, gdzie skierować każdą część płatności.

Dla platform obsługujących klientów firmowych często wygrywa model "pobierz teraz, podziel później" z księgą rozliczeń, bo zamówienie może mieć częściową dostępność, różne terminy wysyłki, akceptację kredytu, ręczne zatwierdzenie sprzedawcy albo podział dostawy. To daje kontrolę, ale zwiększa odpowiedzialność za uzgadnianie rozliczeń i zgodność z przyjętym modelem prawnym.

Nie wybieraj dostawcy płatności przed modelem operacyjnym. Najpierw odpowiedz: czy platforma jest sprzedawcą formalnym, czy jest nim sprzedawca? Czy środki mogą przejść przez platformę? Kiedy sprzedawca ma prawo do wypłaty? Co dzieje się przy częściowym zwrocie? Kto płaci prowizję operatora i koszt sporu płatniczego?

Przepis Medusa dla platformy z wieloma sprzedawcami opisuje wzorzec, w którym tworzysz własny moduł sprzedawców, łączysz sprzedawcę z produktami i zamówieniami, a proces tworzenia zamówienia możesz dostosować tak, aby rozbić jedno zamówienie na wiele zamówień sprzedawców. To dobry punkt startu, bo nie walczysz z zamkniętą ścieżką zakupu w gotowym systemie abonamentowym.

W GMI zwykle projektujemy odpowiedzialność sprzedawcy na poziomie pozycji koszyka: identyfikator sprzedawcy, magazyn, klasa podatkowa, metoda dostawy, reguła prowizji, polityka zwrotu, minimalna wartość zamówienia i uzgodniony czas realizacji. Po zakończeniu procesu zakupowego system tworzy zamówienie nadrzędne dla kupującego oraz zamówienia podrzędne dla operacji sprzedawców.

NestJS sprawdza się jako warstwa domenowa tam, gdzie reguły wychodzą poza rdzeń sprzedaży internetowej: ścieżka akceptacji klientów firmowych, kredyt kupiecki, limity kupieckie, wyceny transportu, niestandardowe ceny, ocena sprzedawcy, integracje z systemem finansowo-magazynowym, bazą produktów i magazynem oraz eksport dokumentów do księgowości.

W platformie dla firm z wieloma sprzedawcami pytanie "kto wystawia fakturę?" jest równie ważne jak "jak dzielimy płatność?". Jeden kupujący może dostać jedną fakturę od platformy, wiele faktur od sprzedawców albo dokument zbiorczy plus dokumenty cząstkowe. Każdy wariant zmienia logikę podatkową, odpowiedzialność za korekty i integrację z systemem finansowo-magazynowym.

Księga rozliczeń powinna przechowywać nie tylko przelewy, ale też ich powód: linię zamówienia, sprzedawcę, prowizję, koszt wysyłki, podatek, zwrot, korektę, spór płatniczy lub ręczną zmianę. Bez tego księgowość będzie eksportować pliki rozliczeniowe i ręcznie szukać różnic między operatorem płatności, systemem finansowo-magazynowym i panelem platformy.

Na etap rozpoznania biznesu, projektu i technologii warto zaprosić finanse i prawnika klienta, nie tylko właściciela produktu. Podział koszyka dotyka umów ze sprzedawcami, regulaminu platformy, weryfikacji klientów i firm, raportowania podatkowego, sporów płatniczych oraz odpowiedzialności za dostawę.

Ścieżka bez problemów jest łatwa: kupujący płaci, sprzedawca wysyła, platforma pobiera prowizję. Prawdziwa złożoność zaczyna się przy częściowych zwrotach. Co jeśli kupujący zwraca jedną linię od trzech sprzedawców, a koszt wysyłki był współdzielony? Co jeśli jeden sprzedawca anuluje realizację po autoryzacji płatności?

System musi obsłużyć częściowe pobranie płatności, częściowy zwrot, zwrot prowizji platformy, korektę wypłaty, aktualizację faktury i statusu zamówień. Jeżeli wypłata do sprzedawcy poszła przed zakończeniem okna zwrotu, potrzebujesz reguł potrąceń, rezerw albo kolejnych kompensacji.

Spór płatniczy jest jeszcze ostrzejszy, bo operator płatności może obciążyć platformę, a problem dotyczy konkretnego sprzedawcy albo dostawy. Bez relacji linia zamówienia -> płatność -> przelew -> faktura -> wysyłka nie ustalisz szybko odpowiedzialności.

Cel projektowania doświadczenia nie polega na tym, żeby udawać, że platforma ma jednego sprzedawcę. Chodzi o to, żeby kupujący rozumiał, co kupuje, od kogo, kiedy dostanie towar i jakie dokumenty otrzyma, ale nie musiał powtarzać płatności trzy razy.

Dobry podzielony koszyk pokazuje grupy sprzedawców, różne dostawy, minimalne wartości zamówienia, terminy, warunki zwrotu i faktury w sposób łatwy do szybkiego przejrzenia. Dla klientów firmowych ważne są też: numer zamówienia zakupu, centrum kosztów, ścieżka akceptacji, kredyt kupiecki, limit kupiecki, konto firmowe i możliwość ponowienia zamówienia.

Warstwa sklepu w Next.js lub aplikacja React Native powinny korzystać z tych samych umów komunikacji z zapleczem. Jeżeli kanał mobilny ma uproszczony koszyk bez informacji o sprzedawcach i podziale wysyłek, później wróci to jako reklamacje, błędne oczekiwania i koszt obsługi klienta.

W GMI zaczynamy od rozpoznania biznesu, projektu i technologii, bo podział koszyka bez wspólnego ustalenia procesów szybko zamienia się w niekontrolowany projekt finansowo-prawny. Mapujemy role platformy, sprzedawców i kupujących, sprzedawcę formalnego, przepływ środków, faktury, zwroty, integracje z systemem finansowo-magazynowym, bazą produktów i magazynem, realizację dostaw oraz minimalny zakres pierwszej wersji produktu.

Typowy zestaw technologii to MedusaJS jako modułowy rdzeń handlu internetowego, warstwa sklepu w Next.js, NestJS dla usług domenowych platformy z wieloma sprzedawcami, PostgreSQL dla księgi rozliczeń i danych transakcyjnych, Redis oraz kolejki dla procesów działających w tle, a także integracja ze Stripe Connect, Adyen, PayPal lub lokalnym operatorem płatności. Jeżeli kanałem sprzedaży jest aplikacja mobilna, dokładamy React Native/Expo na tych samych zasadach wymiany danych z zapleczem.

Po takim rozpoznaniu możemy rozmawiać o stałej cenie, bo znane są ryzyka: model płatności, podatki i VAT, moment wypłaty, wdrożenie sprzedawców, panele administracyjne i sprzedawców, zwroty, wgląd w działanie systemu oraz przekazanie projektu. Klient zachowuje kod źródłowy i architekturę bez uzależnienia od dostawcy technologicznego.

Użyj tej listy przed wyborem platformy, operatora płatności albo partnera technologicznego. Jeśli nie masz odpowiedzi, podział koszyka będzie wyglądał dobrze w prezentacji, ale rozpadnie się w codziennych operacjach.

• Kto jest sprzedawcą formalnym: platforma, sprzedawca czy model mieszany?
• Czy kupujący dostaje jedną fakturę, wiele faktur czy dokument zbiorczy plus dokumenty sprzedawców?
• Czy płatność ma być kierowana do jednego sprzedawcy, pobierana przez platformę i dzielona później, blokowana podobnie do rachunku powierniczego, oparta o kredyt kupiecki czy rozliczana w modelu "najpierw faktura"?
• Kiedy sprzedawca ma prawo do wypłaty: po autoryzacji, pobraniu płatności, wysyłce, dostawie czy końcu okna zwrotu?
• Jak obsługujemy częściowy zwrot, spór płatniczy, anulowanie jednej linii i korektę prowizji?
• Jak księga rozliczeń uzgadnia operatora płatności, zamówienia sprzedawców, dokumenty fakturowe i system finansowo-magazynowy?
• Które elementy pierwszej wersji są konieczne: wdrożenie sprzedawców, weryfikacja firm i klientów, panel sprzedawcy, obsługa sporów, podział wysyłek, limity kredytowe?