Najgroźniejsza integracja dostaw nie jest tą, która przestaje działać. Jest nią ta, która zgłasza „sukces”, choć checkout nadal nalicza błędną stawkę.
Shopify rozpoczął wdrażanie market-driven shipping 1 października 2026 r. Platforma przenosi reguły dostaw zarządzane przez sprzedawcę z profili wysyłkowych do Markets. Wygląda to na zmianę w panelu administracyjnym, ale dla sklepów połączonych z ERP, OMS, 3PL lub własną aplikacją wysyłkową oznacza zmianę źródła prawdy. [1][2]
W skrócie
W sklepach po migracji odczyty ze starego API profili dostaw mogą zwracać nieaktualną konfigurację, a zapisy mogą kończyć się sukcesem bez zmiany rzeczywistych reguł wysyłki. Dostawy konfigurowane przez sprzedawcę przechodzą do Markets, natomiast profile zarządzane przez aplikacje pozostają wspierane. Przed włączeniem nowego modelu sprawdź integracje, szczególnie jeśli jedno zamówienie może obejmować kilka przesyłek albo wysyłkę i odbiór osobisty. [2][3]
Spis treści
- Co zmieniło się w październiku
- Cichy błąd, który naprawdę ma znaczenie
- Przykład stawek 5 € i 9 €
- Jedno zamówienie nie zawsze oznacza jedną dostawę
- Praktyczny audyt integracji
- Co zrobić przed migracją
- Decyzja operacyjna
1. Co zmieniło się w październiku
W poprzednim modelu sprzedawca konfigurował zwykle profil dostaw, grupy lokalizacji, strefy i stawki wysyłki. W modelu market-driven shipping definiuje opcje dostawy w Markets, a następnie różnicuje je według produktu i lokalizacji realizacji. Shopify uruchomił możliwość samodzielnego przejścia na nowy model 1 października 2026 r., a zakończenie migracji planuje na 1 lipca 2027 r. Wdrożenie jest stopniowe: nie wszystkie istniejące sklepy zostały przełączone pierwszego dnia. [1][2]
To ważne rozróżnienie. W sklepie korzystającym ze starego modelu operacje na profilach dostaw mogą nadal działać prawidłowo. Po migracji sytuacja może być inna. Ta sama aplikacja może więc zachowywać się inaczej w dwóch sklepach tego samego dnia. Shopify udostępnia flagę marketDrivenShipping, która pozwala integracji rozpoznać aktywny model. [2]
W roadmapie Shopify wskazano też 12 października 2026 r. jako etap rozszerzania obsługi łączonej wysyłki i odbioru osobistego przez Cart API. To data z harmonogramu produktu, a nie dowód, że funkcja jest już aktywna w każdym sklepie. [1]
2. Cichy błąd, który naprawdę ma znaczenie
Shopify wyraźnie ostrzega, że po przejściu sklepu na market-driven shipping starsze zapytania Admin GraphQL do profili dostaw mogą zwracać nieaktualny stan konfiguracji. Co gorsza, operacje zapisu dotyczące profili należących do sprzedawcy mogą zakończyć się bez błędów, ale nie zmienić aktywnych ustawień wysyłki. Osobnym przypadkiem są profile należące do aplikacji: te nadal działają. [3]
Wyobraź sobie integrację ERP, która aktualizuje strefę dostawy po uruchomieniu magazynu w kolejnym kraju. W logach widać udaną mutację, a dashboard oznacza operację jako zakończoną. Checkout nadal korzysta jednak z aktywnej opcji dostawy zapisanej w Markets, której nikt nie zaktualizował. Problem wychodzi na jaw dopiero wtedy, gdy klient płaci niewłaściwą stawkę lub nie widzi dostępnej metody dostawy.
To przykład hipotetyczny, a nie opis zgłoszonego incydentu. Wniosek jest operacyjny: sukces odpowiedzi API nie oznacza, że checkout działa poprawnie. Monitoring musi sprawdzać stawkę widoczną dla klienta, a nie tylko wynik mutacji.
3. Przykład stawek 5 € i 9 €
Nową logikę łączenia stawek łatwo źle zinterpretować. Shopify opisuje opcję dostawy Standard, w ramach której pasują dwie stawki ryczałtowe. Gdy jeden produkt ma stawkę 5 €, a drugi 9 € w tej samej opcji, checkout pobiera wyższą pasującą stawkę, czyli 9 €, zamiast sumować je do 14 €. Są to kwoty ilustrujące udokumentowaną zasadę łączenia stawek, a nie obowiązujący cennik Shopify. [4]
| Koszyk | Stawki w opcji Standard | Wynik w checkout |
|---|---|---|
| Produkt A | 5 € | 5 € |
| Produkt B | 9 € | 9 € |
| A + B | 5 € i 9 € | 9 € |
Nie oznacza to jednak zasady „wysyłka zawsze kosztuje tyle, co najwyższa stawka”. Opłaty należące do różnych opcji dostawy mogą się sumować. Stawki wagowe i wyliczane przez przewoźnika mogą być obliczane osobno dla każdej przesyłki, a następnie dodawane. Przesyłki preorderowe mają własne reguły łączenia. ERP prognozujący przychód lub marżę na podstawie uproszczonego wzoru może więc pokazywać inne wartości niż checkout, nawet jeśli bazowa tabela stawek jest prawidłowa. [4]
Załóżmy ilustracyjnie 1000 zamówień miesięcznie, w których błędna reguła zawyża lub zaniża opłatę o 5 €. Oznacza to 5000 € miesięcznej różnicy w naliczeniach, jeszcze przed uwzględnieniem wpływu na konwersję, koszty przewoźnika czy zwroty. To prosta arytmetyka, a nie zmierzona strata branży. Chodzi o skalowanie się nawet niewielkich błędów w stawkach wraz z liczbą zamówień.
4. Jedno zamówienie nie zawsze oznacza jedną dostawę
W kwalifikujących się organizacjach Shopify Plus i Enterprise funkcja testowa ship-and-pickup pozwala klientowi wybrać odbiór osobisty dla części produktów i wysyłkę dla pozostałych w jednym checkout. Według Shopify ogólna dostępność na planie Plus jest planowana na 1 lipca 2027 r. Zamówienia łączące różne metody tworzą osobne realizacje pogrupowane według sposobu dostawy. [1][5]
Przykład: klient kupuje ekspres do kawy i ziarna. Ekspres jedzie z magazynu, a ziarna czekają na odbiór w sklepie. Connector, który wysyła wszystkie pozycje do 3PL tylko dlatego, że zamówienie ma adres dostawy, może nadać towar, który miał zostać na półce punktu odbioru. Aplikacja powiadomień zakładająca jedną metodę dostawy może wysłać mylące potwierdzenie. [5]
Shopify zaleca, aby integracje OMS i fulfilment sprawdzały metodę dostawy na poziomie fulfilment orders. Testów wymagają również ubezpieczenia przesyłek, checkout extensions, rabaty i wiadomości transakcyjne. To problem operacyjny, a nie wyłącznie kwestia wyglądu checkout. [5]
5. Praktyczny audyt integracji
- Zmapuj zależności. Znajdź wszystkie wywołania
deliveryProfile,deliveryProfiles,deliveryProfileCreate,deliveryProfileUpdateideliveryProfileRemove. Ustal, czy każda operacja dotyczy konfiguracji sprzedawcy, czy aplikacji. [2] - Rozpoznaj model wysyłki. Sprawdzaj flagę
marketDrivenShippingsklepu przed wyborem sposobu odczytu i zapisu. Nie wyciągaj wniosków z daty utworzenia sklepu ani wersji API. [2] - Wybierz odpowiednik starej operacji. Przy odczytach dla kanałów sprzedaży Shopify zaleca tam, gdzie to właściwe, Contextual Product Feeds. Pozostałe integracje mogą korzystać z
Market.delivery. Zapis można realizować przez profil dostaw zarządzany przez aplikację albo Markets API, zależnie od właściciela stawki. Sprawdź wymagane zakresy uprawnień. [2] - Testuj cenę pokazywaną klientowi. Przygotuj koszyki z jednym produktem, mieszanymi kolekcjami, progami darmowej dostawy, wieloma lokalizacjami, preorderami i stawkami obliczanymi przez przewoźnika. Porównuj oczekiwane wartości z rzeczywistym checkout, a nie tylko z odpowiedziami API. [4]
- Przetestuj fulfilment orders. W kwalifikujących się sklepach testowych sprawdź, czy pozycje do odbioru osobistego nie trafiają do operatora wysyłkowego, podzielone przesyłki prawidłowo się uzgadniają, a powiadomienia pokazują właściwe metody dostawy. [5]
- Wprowadź weryfikację po zapisie. Po zmianie konfiguracji odczytaj obowiązujące ustawienia Markets i wykonaj test stawki w checkout. Uruchom alert, gdy zapis API kończy się sukcesem, ale wynik widoczny dla klienta odbiega od oczekiwań.
6. Co zrobić przed migracją
Shopify deklaruje, że sklepy z niekompatybilnymi aplikacjami nie będą migrowane automatycznie, dopóki zgodność nie zostanie potwierdzona. Sprzedawca może jednak samodzielnie włączyć nowy model i natrafić na problemy. Nowe instalacje aplikacji mogą od październikowego wdrożenia wyświetlać ostrzeżenia o kompatybilności. Do 1 lipca 2027 r. Shopify planuje uczynić market-driven shipping standardowym modelem dla wszystkich sklepów. Są to terminy z opublikowanego planu, które mogą się zmienić. [1][2]
Z perspektywy operatora kolejność jest prosta: zrób inwentaryzację aplikacji wysyłkowych i własnych integracji, uzyskaj od dostawców potwierdzenie kompatybilności, przetestuj reprezentatywne scenariusze checkout, opisz oczekiwane mapowanie zamówień na realizacje, a dopiero potem podejmij decyzję o migracji. Sam fakt, że sklep używa Shopify Shipping albo ma zainstalowaną aplikację 3PL, nie dowodzi zgodności.
Dostawca integracji powinien wspierać oba modele w okresie przejściowym. Starą ścieżkę można wycofać dopiero, gdy klienci nie będą jej już potrzebować. Co ważniejsze, log „wywołanie API zakończone sukcesem” trzeba zastąpić kontrolą, która potwierdza poprawność aktywnej stawki i ścieżki realizacji.
7. Decyzja operacyjna
Ryzyko biznesowe nie wynika z przeniesienia ekranu ustawień Shopify. Wynika z tego, że wysyłka zależy teraz od kontekstu rynku, warunków produktowych i metody realizacji, podczas gdy część integracji nadal zakłada jeden profil oraz jedną metodę dostawy na poziomie zamówienia. Sklep może wyglądać poprawnie w ERP, a mimo to źle naliczać stawki w checkout.
Audytuj połączenia przed migracją, nie reklamacje po niej. Jeżeli reguły dostaw, Markets i routing zamówień obejmują kilka systemów, Pleroma Commerce może pomóc zmapować zależności i przełożyć je na testowalny plan integracji.
Źródła
- Shopify Developer Blog, The next generation of Shopify fulfillment is coming, 7 lipca 2026 r.
- Shopify Developers, Upgrade your app for market-driven shipping, dostęp 13 października 2026 r.
- Shopify Developer Changelog, Merchant-owned delivery profile APIs are deprecated, 1 lipca 2026 r.
- Shopify Help Center, Understanding shipping options by market, dostęp 13 października 2026 r.
- Shopify Help Center, Ship and pickup in one order in Shopify Checkout, dostęp 13 października 2026 r.
