Programista WooCommerce w Stuttgarcie

Sklep WooCommerce w Stuttgarcie stoi obok Porsche AG w Zuffenhausen, Mercedes-Benz w Untertürkheim i hal Messe Stuttgart przy Flughafenstraße. Kupujący płaci PayPalem albo Klarna, odbiera w Packstation w Vaihingen albo w Esslingen am Neckar i oczekuje faktury, którą Steuerberater wczyta do DATEV. Checkout skopiowany z innego rynku - karta na pierwszym miejscu, brak Lastschrift, giropay wciąż w liście metod - gubi zamówienia zanim ktokolwiek oceni specyfikację części zamiennej. Ta strona opisuje budowę i naprawę sklepu: katalog, checkout, płatności, dostawy, stany i zwroty. Nie opisuje opieki serwera ani motywu korporacyjnego.

Zakres pokrywa programistę WooCommerce w warunkach niemieckich. Strona firmowa bez koszyka to osobna ścieżka: programista WordPress w Stuttgarciu. Sklep już na produkcji, który potrzebuje aktualizacji i kopii, a nie przebudowy checkoutu, idzie na opiekę techniczną WordPress w Stuttgarciu.

#Checkout WooCommerce w Stuttgarcie

Stuttgart spina trzy rzeczy, które rzadko spotykają się w jednym mieście w takiej skali. Po pierwsze motoryzację i łańcuch dostaw: Porsche AG ma siedzibę i główną fabrykę w Zuffenhausen, Mercedes-Benz Group AG ma centralę w Stuttgarcie, a zakład montażowy w Untertürkheim leży tuż obok muzeum marki. Po drugie Mittelstand: region Stuttgart i Neckar-Alb to jeden z najgęstszych klastrów dostawców Tier-2 i Tier-3 w Europie, a inicjatywa CARS 2.0 (Cluster Automotive Region Stuttgart 2.0), koordynowana przez Wirtschaftsförderung Region Stuttgart GmbH, wspiera małe i średnie firmy z automotive i maszynownictwa w transformacji cyfrowej. Po trzecie kalendarz targów: Messe Stuttgart (Landesmesse Stuttgart) przy lotnisku to miejsce, gdzie w 2026 roku odbyły się między innymi CMT (17-25 stycznia) oraz LogiMAT (24-26 marca, ponad 1600 wystawców intralogistyki).

Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż B2C z Packstation w Ludwigsburgu, Böblingen albo przy A8/A81 oraz skoki katalogu przed LogiMAT albo jesiennym cyklem targów (AMB, Vision, Battery Show Europe), gdy hurt z Esslingen am Neckar albo z magazynu przy Messe musi wyjechać paletami DHL, a nie skrytką.

Dostawca z Esslingen, producent komponentów z Ludwigsburgu albo firma usługowa z Vaihingen an der Enz potrzebuje sklepu B2B, który nie brzmi jak szablon z marketplace, ale ma ten sam rejestr formalny co katalog PDF wysyłany do działu zakupów Zuffenhausen. Ceny netto, pole USt-IdNr., Vorkasse i paletowa wysyłka to nie opcje premium. To warunek, żeby zamówienie w ogóle przeszło u Steuerberatera.

Prace trzymają się WooCommerce. Customizacje idą przez hooki action i filter oraz własną wtyczkę, nigdy przez edycję plików rdzenia. Granica między rdzeniem Woo, kodem wtyczki i motywem zapada na audycie i trafia do runbooka.

#Płatności na checkoucie w Niemczech w 2026

Niemiecki koszyk nie zaczyna się od karty. PayPal pozostaje portfelem, którego kupujący szuka w pierwszym ekranie metod. Klarna pokrywa Kauf auf Rechnung, Pay Later i raty na wyższy koszyk części zamiennych albo wyposażenia wystawienniczego. SEPA Lastschrift (Lastschriftverfahren) jest nadal standardem przy subskrypcjach, B2B i powtarzalnych zamówieniach z central w Baden-Württembergii. Karta przez Stripe albo Mollie zostaje jako warstwa uniwersalna z SCA i 3DS. Vorkasse, czyli przelew z góry na IBAN sklepu, zostaje przy hurtcie Tier-2 i przy zamówieniach, których sklep nie wyśle, zanim księgowość zobaczy wpływ.

giropay nie jest metodą bieżącą. Niemieckie banki wyłączyły usługę z końcem grudnia 2024. paydirekt skończył się w tym samym oknie. Checkout, który w 2026 nadal pokazuje giropay, kończy się twardym błędem bramki i utratą zaufania. Wero (European Payments Initiative) wchodzi do banków latach 2024-2026, ale nie jest jeszcze metodą, którą warto stawiać jako domyślną w Woo, dopóki wybrany PSP nie ma stabilnego webhooka i testów zwrotu.

Kolejność metod na checkoucie ustawiamy pod ten mix: PayPal i Klarna wysoko, Lastschrift tam gdzie sklep ma mandaty, karta niżej, Vorkasse tylko w ścieżce B2B. Domyślny szablon Woo z kartą na górze pracuje wbrew nawykom rynku niemieckiego, w tym kupującego z Stuttgartu, który woli portfel albo odroczoną płatność przy koszyku powyżej kilkuset euro.

Dla każdej bramki w runbooku zostaje: obsługiwane flow (jednorazowe, cykliczne, capture, zwrot pełny, zwrot częściowy), adres webhooka, lista zdarzeń które zmieniają status, matryca kont sandbox i historia idempotencji. PayPal w praktyce zgłasza capture i odmowę osobnymi zdarzeniami. Klarna wymaga osobnej decyzji, czy capture idzie od razu, czy po nadaniu przesyłki - przy towarze fizycznym z magazynu w Esslingen druga opcja chroni przed pobraniem pieniędzy za SKU, którego nie ma. SEPA Lastschrift wymaga zapisanego mandatu, pre-notification i świadomości okna chargebacku po stronie konsumenta; sklep, który oznacza zamówienie jako completed w sekundę po złożeniu Lastschrift, kłóci się z rzeczywistością księgową.

#Strefy dostaw: DHL Paket, Packstation i kurier gabarytowy

Krajowa dostawa z Niemczech w 2026 to przede wszystkim DHL Paket. Oficjalna wtyczka DHL for WooCommerce (DHL Shipping Germany) obsługuje DHL Paket z Niemiec oraz Deutsche Post International na wysyłki europejskie. Konfiguracja biznesowa wymaga numeru EKP (dziesięć cyfr) i numerów uczestnictwa (Teilnahmenummern) z portalu Geschäftskunden. Wtyczka nie dodaje osobnej metody do listy stref Woo. Przypina się ją do istniejącej stawki ryczałtowej, darmowej dostawy albo odbioru osobistego, a potem mapuje produkty DHL (Paket, Kleinpaket, Warenpost, warianty międzynarodowe) w ustawieniach DHL Paket.

Packstation jest w Niemczech odpowiednikiem automatu, którego checkout musi obsłużyć w polach adresu, a nie w notatce do zamówienia. Poprawny adres REST to: Postnummer klienta, ulica Packstation, numer domu równy numerowi stacji, kod pocztowy i miasto stacji, kraj Niemcy. Location Finder we wtyczce DHL wypełnia te pola sam. Ręczne wpisanie “Packstation” w linii adresu bez Postnummer kończy się odrzuceniem etykiety: brak numeru domu albo brak kodu routingu. Mapa punktów działa dla destynacji niemieckiej; nie należy obiecywać Packstation przy wysyłce do Francji albo do Polski z tej samej instancji wtyczki.

Kurier gabarytowy (DPD albo DHL do drzwi) wchodzi tam, gdzie gabaryt nie wejdzie do skrytki: stoiska wystawiennicze po LogiMAT, kartony katalogów po CMT, zestawy B2B z hurtowni w Esslingen. Strefy Woo rozdzielamy więc nie tylko na “Niemcy / UE / reszta świata”, ale na wagę i wymiar: do progu Packstation albo filia DHL, powyżej kurier do drzwi. Lokalny odbiór w aglomeracji (Stuttgart, Esslingen, Ludwigsburg, Böblingen, Waiblingen) ma osobną metodę z jasnym adresem magazynu.

Etykieta i numer śledzenia wracają do zamówienia Woo i do maila klienta. Generowanie etykiety po payment_complete zdejmujemy do Action Scheduler (as_enqueue_async_action), żeby handler webhooka oddał 200 zanim DHL API policzy routing. Ręczne klejenie etykiet w portalu DHL przy liczbie zamówień po tygodniu LogiMAT nie skaluje się.

#MwSt, OSS i pole VAT-ID

Stawki krajowe w 2026 pozostają 19 procent (reguła) i 7 procent (stawka obniżona, m.in. książki i część żywności). Koszyk mieszany jest codziennością przy sklepie części zamiennych albo wystawienniczym, który sprzedaje katalog targowy obok gadżetu albo książkę obok elektroniki. Woo musi liczyć podatek per pozycja, a nie “weź najwyższą stawkę koszyka”. Błąd w klasie podatkowej produktu wychodzi dopiero na fakturze i w eksporcie DATEV.

Sprzedaż B2C do innych krajów UE po przekroczeniu unijnego progu OSS idzie stawką kraju destynacji, nie niemieckim 19 procent. Woo sam z siebie nie jest modułem OSS. Albo wtyczka podatkowa liczy stawki destynacji i sklep raportuje przez One-Stop-Shop, albo ERP jest źródłem podatku, a Woo tylko zbiera adres i kwoty. Mieszanie obu źródeł to najczęstszy rozjazd w deklaracji.

B2B wewnątrzunijne z ważnym VAT-ID idzie jako dostawa wewnątrzwspólnotowa (0 procent), o ile numer przejdzie walidację VIES i sklep zapisuje dowód sprawdzenia przy zamówieniu. Pole USt-IdNr. na checkoucie, walidacja i przełączenie klasy podatkowej to nie ozdoba formularza. Przy Vorkasse B2B to samo pole decyduje, o tym czy faktura w ogóle ma szansę przejść u Steuerberatera w Stuttgarciu albo w Esslingen, gdy spółka ma dwie siedziby w aglomeracji Neckar.

Granicę “co liczy podatek i wystawia dokument” zapisujemy w runbooku: Germanized albo German Market w Woo, osobny silnik faktur, albo system księgowy. Jedno źródło numeracji. Dwa źródła dają podwójne numery albo dziury, a GoBD tego nie wybacza.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Stuttgarcie, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu “Jetzt kaufen” albo “PayPal”. Sklep z magazynem w Esslingen, który sprzedaje równolegle przez własne Woo i przez marketplace, płaci za ten błąd dwa razy: raz zamówieniem w limbo, drugi raz nadsprzedażą SKU, który był już zarezerwowany w drugim kanale.

#Status zamówienia ustala serwer, nie powrót klienta

Status zamówienia ustala powiadomienie serwer do serwera. Powrót klienta na stronę podziękowania nie jest źródłem prawdy. Endpoint order-received to zdarzenie przeglądarki. Przeglądarka jest zawodna: po autoryzacji PayPal klient zamyka kartę w ICE między Stuttgart Hbf a Messeplatz, traci sieć w parkingowym domu przy lotnisku, wraca z cache. Hook woocommerce_thankyou służy do wyświetlenia treści. Nie zmienia statusu płatności.

O pieniądzach decyduje callback bramki. W Woo odbiera go własny adres zwrotny z parametrem wc-api, czyli akcja z rodziny woocommerce_api_ rejestrowana przez wtyczkę bramki. Handler po weryfikacji sygnatury wywołuje payment_complete na obiekcie zamówienia i przenosi je z pending do processing. Sygnaturę sprawdzamy na surowym ciele żądania ze strumienia php://input, zanim cokolwiek zostanie sparsowane. Cięższą pracę po weryfikacji - synchronizację magazynu, wystawienie dokumentu, nadanie DHL - zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i PayPal, Mollie albo Klarna nie zaczęły ponawiać.

Powtórzony sygnał z bramki jest normą, nie awarią. Bramki ponawiają webhook przy timeoutach i przy każdym błędzie po stronie sklepu. Ta sama płatność potrafi przyjść kilka razy, czasem równolegle z powrotem klienta. Identyfikator zdarzenia zapisujemy w meta zamówienia i sprawdzamy przed przetworzeniem. Blok obsługi obudowujemy blokadą: wp_cache_add na trwałym cache obiektowym (Redis) albo add_option z wyłączonym autoloadem. Obie operacje są atomowe i pierwsza wygrywa. Zamówienie już opłacone nie zmienia stanu drugi raz. Dostaje notatkę o zignorowanym duplikacie.

Płatność odrzucona i zwrot częściowy to dwie osobne ścieżki. Odrzucenie ustawia status failed, nie cancelled, bo zamówienie ma nadal dać się opłacić: klient dostaje link z get_checkout_payment_url. Zwrot częściowy idzie przez wc_create_refund z listą pozycji i kwot oraz z flagą zwrotu na bramce. Zamówienie zostaje w processing albo completed, a zwróconą kwotę czyta się z get_total_refunded, nie ze statusu. Traktowanie każdego zwrotu jak pełnego anulowania psuje raport sprzedaży i stany po sezonie Widerruf.

#Rezerwacja magazynu i sprzedaż wielokanałowa

Stan rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce od wersji 4.3 zapisuje rezerwację w tabeli wp_wc_reserved_stock przez wc_reserve_stock_for_order, zwalnia ją przez wc_release_stock_for_order, a czas trzymania bierze z opcji woocommerce_hold_stock_minutes. Bez tego dwoje kupujących wchodzi w PayPal na ostatnią sztukę limitowanego SKU z kolekcji po LogiMAT i oboje dostają potwierdzenie. Faktyczne odjęcie stanu robi wc_maybe_reduce_stock_levels i pilnuje go flaga _order_stock_reduced, dzięki czemu powtórzony webhook nie odejmuje towaru drugi raz.

Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o Amazon, Otto albo innym kanale. Źródłem prawdy zostaje wspólna pula w ERP albo w warstwie fulfilment, a Woo trzyma stan przez synchronizację. Rezerwacja lokalna chroni wtedy tylko przed kolizją w obrębie sklepu. Mapowanie SKU, jednostek i klas podatkowych ustalamy na architekturze, bo to ono, a nie sama wtyczka, decyduje czy synchronizacja jest spójna.

Hold stock przy Vorkasse ustawia się dłużej niż przy PayPal: przelew z banku spółdzielczego albo Sparkasse potrafi iść do następnego dnia roboczego. Zbyt krótki hold zdejmuje rezerwację, zanim księgowość zaksięguje wpływ, i sklep sprzedaje ten sam karton drugi raz.

#Tabele wp_wc_orders i tryb zgodności

High-Performance Order Storage jest domyślny dla nowych instalacji od WooCommerce 8.2 (październik 2023). Zamówienia żyją wtedy w wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data i wp_wc_orders_meta, a nie jako wpisy shop_order w wp_posts. Sklepy postawione wcześniej przełączają się świadomie: najpierw tryb zgodności (synchronizacja dwukierunkowa), potem HPOS jako magazyn autorytatywny, na końcu wyłączenie dual-write gdy raporty i wtyczki przestaną się rozjeżdżać.

Diagnostyka i raporty idą przez wc_get_orders oraz OrderUtil, nie przez SQL w wp_posts. Wtyczka, która w 2026 nadal szuka zamówień wyłącznie w postmeta, na HPOS pokazuje puste listy, psuje eksport DATEV i gubi zwroty. Germanized, German Market, oficjalne DHL, PayPal Payments, Stripe i Mollie są na HPOS od dawna. Problemem są stare konektory magazynowe i autorskie crony. Audyt HPOS to lista wtyczek, które czytają zamówienia, plus wp wc hpos status na stagingu, plus zamówienie testowe z webhookiem, zanim produkcja dostanie przełączenie.

Log ma pozwolić odtworzyć historię zamówienia bez logowania do panelu PayPal albo Klarna. Do dziennika przez wc_get_logger z własnym źródłem trafia identyfikator zdarzenia, status przed i po, kwota, wynik weryfikacji sygnatury i decyzja (przetworzono albo pominięto jako duplikat). Nie trafia pełny payload z danymi płatniczymi. Pliki lądują w wp-content/uploads/wc-logs/. Równolegle każda istotna zmiana dostaje add_order_note, żeby obsługa klienta w Zuffenhausen widziała tę samą historię co programista.

#Faktury, GoBD i eksport DATEV

Sklep w Stuttgarcie rzadko jest systemem księgowym. Jest źródłem zdarzeń sprzedaży, które Steuerberater ma wciągnąć do DATEV. GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern) wymaga kolejnych numerów dokumentów, niezmienialności wystawionej faktury i ścieżki audytu. Woo, które pozwala “poprawić” kwotę na wystawionym PDF, psuje ten łańcuch. Korekta idzie dokumentem korygującym albo wc_create_refund, nie edycją starego pliku.

Eksport DATEV w praktyce to plik EXTF albo CSV księgowań plus paczka PDF. Mapowanie kont idzie zwykle w SKR 03 albo SKR 04, uzgodnione ze Steuerberaterem: osobne konta przychodu dla 19 procent i 7 procent, osobne dla dostaw wewnątrzwspólnotowych, osobne konta przejściowe per bramka (PayPal, Klarna, Stripe, Mollie, bank przy Vorkasse), osobne księgowanie zwrotu. Typowy błąd to wrzucenie opłaty bramki i przychodu na jedno konto. Drugi to brak zwrotów eksporcie, gdy sezon Widerruf już zdążył odwrócić marżę miesiąca.

Automotive Mittelstand z Esslingen albo Ludwigsburgu dokłada trzecią oś, której GoBD nie rozwiązuje za zespół. Sklep B2B wystawia fakturę z numerem seryjnym części, katalog PDF z certyfikatem IATF 16949 i eksport CSV do DATEV. Jeśli numer faktury skacze, bo ktoś ręcznie edytował zamówienie w panelu, audyt jakości w Zuffenhausen pyta o spójność dokumentów. Woo musi trzymać numerację w jednym źródle.

Okres przechowywania dzienników Woo, PDF i eksportów uzgadniamy z księgowością. Retencja “kasuj logi po siedmiu dniach”, sensowna przy debugowaniu, jest za krótka gdy przyjdzie Fragebogen z Finanzamt. To decyzja operacyjna sklepu, nie ozdoba wtyczki logów.

OSS, split payment i odwrotne obciążenie nie mieszkają w motywie. Mieszkają w klasach podatkowych, w numerze VAT nabywcy i w tym, czy eksport DATEV widzi te same stawki co checkout. Jeśli nie widzi, naprawa jest w mapowaniu, nie w CSS.

#Zwroty i Widerruf jako operacje sklepu

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty Impressum, AGB i Widerrufsbelehrung zatwierdza kancelaria albo odpowiedzialny w firmie. Zadaniem Woo jest spiąć ten tekst z koszykiem, z przyciskiem, z mailem i z magazynem.

Konsument w Niemczech ma 14 dni na odstąpienie od umowy zawartej na odległość. Termin zaczyna biec, gdy Belehrung została udzielona poprawnie. Brak albo błąd Belehrung wydłuża okno - w praktyce nawet do dwunastu miesięcy i czternastu dni. Dla magazynu w Esslingen to nie ciekawostka z BGB. To SKU, którego nie wolno sprzedać drugi raz, bo może wrócić za trzy kwartały.

Od 19 czerwca 2026 sklepy B2C muszą dodatkowo dać elektroniczną funkcję odstąpienia (potocznie Widerrufsbutton) na podstawie par. 356a BGB, w ślad za dyrektywą UE 2023/2673. W praktyce Woo: widoczny przycisk w stylu “Vertrag widerrufen”, dostępny bez logowania, proces dwustopniowy (formularz, potem potwierdzenie), automatyczny mail o przyjęciu oświadczenia. Germanized od wersji 4.0 i German Market od wersji 3.58 dostarczają tę ścieżkę. Sam przycisk w stopce bez powiązania z zamówieniem, bez restocku i bez zwrotu na oryginalną bramkę jest dekoracją.

Ścieżka operacyjna, którą budujemy:

1. Klient składa Widerruf z numerem zamówienia albo danymi, które pozwalają je znaleźć w wp_wc_orders.
2. Sklep ustawia status RMA, wysyła potwierdzenie i - jeśli towar fizyczny - etykietę zwrotną DHL albo instrukcję nadania.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na PayPal, Klarna, Mollie albo przelew zwrotny przy Vorkasse.
4. Częściowy Widerruf (jedna pozycja z trzech) nie zamyka całego zamówienia i nie zwraca kosztów wysyłki w ciemno; kwoty bierze się z pozycji, nie z ręcznego “zwróć wszystko”.
5. Towar wyłączony z Widerruf (higiena, personalizacja, treść cyfrowa po rozpoczęciu) musi mieć tę informację przy SKU przed zakupem. Checkout, który o tym milczy, spycha spór na obsługę.

Packstation przy zwrocie działa inaczej niż przy nadaniu. Klient oddaje paczkę w filii albo automacie według reguł DHL Retoure. Adres zwrotny magazynu w Esslingen musi być w kontrakcie DHL, inaczej etykieta zwrotna wskaże biuro przy Hauptbahnhof, gdzie nikt nie przyjmie palety.

Sezon po świętach i po targach Messe to test tej ścieżki. Sklep, który w styczniu ręcznie klika zwroty w panelu PayPal, a stany poprawia w Excelu, rozjeżdża DATEV i nadsprzedaje wracający towar.

#Katalog i checkout pod kalendarz Messe Stuttgart

LogiMAT, CMT, AMB, Vision, Battery Show Europe - to nie tło miasta. To skoki SKU, preorderów i holdów. Katalog, który przez jedenaście miesięcy ma 800 pozycji, przed LogiMAT dostaje warstwę limitowanych zestawów, cen obowiązujących “do wyczerpania zapasu na stoisku” i wariantów, których nie ma w stałej ofercie. Woo musi to udźwignąć bez zgonu strony kategorii.

Daty 2026, które wpisujemy w runbook wydań sklepu:

Wydarzenie	Daty 2026	Wpływ na sklep
CMT	17-25 stycznia	preorder, freeze checkoutu, skok zwrotów po targach
LogiMAT	24-26 marca	hurt B2B intralogistyki, Vorkasse, palety z Esslingen
Transformations-Gipfel	8 października (ARENA2036)	skok zapytań B2B, dłuższy hold stock
Zulieferertag	21 października (Esslingen)	zamówienia z VAT-ID, netto plus MwSt
AMB / Vision / Battery Show	październik	gabaryt, kurier zamiast Packstation

Nowa architektura checkoutu, przełączenie HPOS albo zmiana mapy stref DHL nie wchodzi na produkcję w tych oknach. Tydzień przed LogiMAT i przed jesiennym cyklem targów produkcja nie dostaje “drobnej aktualizacji SEO”. Drobna aktualizacja SEO w piątek przed otwarciem hal potrafi nadpisać robots, wyciąć landing z indeksu albo zepsuć cache strony rejestracji. Daty żyją w runbooku, nie w hardcoded stringu w motywie.

Warianty trzymamy jako prawdziwe variation z własnym SKU, wagą i klasą podatkową, nie jako pole tekstowe “wpisz kolor”. Duża macierz (materiał × wymiar × wykończenie przy częściach zamiennych) dostaje własne zapytania i cache fragmentów. Filtrowanie po atrybucie, które na stagingu działa na 40 SKU, na produkcji z 4 000 wariantów potrafi zabić checkout, bo mini-cart liczy te same joiny.

Preorder przed targami: SKU jest widoczny, płatność schodzi, ale fulfillment stoi aż do daty. Status on-hold albo własny status “warte na magazyn Messe” musi blokować etykietę DHL. Inaczej wtyczka DHL nada pustą paczkę pod Packstation w Vaihingen. Hold stock na preorderze jest dłuższy niż na towarze z półki.

Ceny netto / brutto na checkoucie B2B (netto plus MwSt) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z VAT-ID w Esslingen oczekuje netto. Konsument z aglomeracji oczekuje brutto. Mieszanie obu w jednym podsumowaniu to klasyczny powód porzucenia koszyka, który wygląda jak “błąd podatku”, a jest błędem roli klienta.

Język checkoutu: sklep w Stuttgarcie często idzie po niemiecku jako kanon, z angielskim dla gości targowych. WPML WooCommerce Multilingual albo TranslatePress nie mogą rozjechać klas podatkowych i metod dostaw między językami. Tłumaczenie nazwy metody “DHL Packstation” nie może stworzyć drugiej, nieprzypiętej metody w strefie.

#Stuttgart jako kontekst automotive Mittelstand, nie jako ozdobnik

Stuttgart ma własny ekosystem startupów i technologii, ale sklepy WooCommerce, które tu budujemy, zwykle obsługują Mittelstand: dostawców Tier-2 i Tier-3 z Esslingen, Ludwigsburgu, Vaihingen an der Enz, Böblingen i Waiblingen. ARENA2036 w Stuttgarcie-Vaihingen i ekosystem startupów wspierany przez WRS dokładają recenzentów, którzy czytają pull request. Hochschule der Medien, Universität Stuttgart i okoliczne uczelnie dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki.

Typowy brief, który trafia do seniorów, nie brzmi “zróbcie ładny sklep”. Brzmi: odziedziczony Woo z 35 wtyczkami, checkout który gubi webhook PayPal, magazyn w Esslingen synchronizowany ręcznie z Excela, Steuerberater czeka na DATEV, a za tydzień startuje LogiMAT. To jest problem checkoutu, webhooków i HPOS, nie problem szablonu z marketplace.

IHK Region Stuttgart i Südwestmetall dokładają recenzentów, którzy pytają, czy sklep dostawcy nie udaje produktu OEM. Oba pytania są zdrowe. Odpowiedź siedzi w copy, w numeracji faktur i w tym, czy checkout obsługuje Vorkasse B2B z VAT-ID, nie w kolejnej wtyczce slidera.

WordPress Meetup Stuttgart (wpmeetup-stuttgart.de, RegioHelden GmbH przy Rotebühlstr. 50) to lokalny barometr ekosystemu, nie zamiennik audytu checkoutu. W 2026 roku w programie były m.in. spotkania o KI w treściach (2 września), rundę pluginów (czerwiec) i wieczór o pomiarze wydajności (maj). Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst. Sklep, który łamie edytor albo checkout, wyjdzie na meetupie szybciej niż w tickecie.

#Wydajność koszyka i checkoutu

Checkout jest dynamiczny. Pełny page cache na cart i checkout serwuje cudzy koszyk albo pusty fragment mini-cart. Warstwa cache (Redis, Cloudflare) omija te ścieżki albo stosuje segmentację. Fragmenty mini-cart liczymy osobno. Skrypty PayPal, Klarna i DHL Location Finder ładujemy wtedy, gdy checkout jest na ekranie, z preconnect do ich domen, nie w stopce każdej strony kategorii.

Obrazy katalogu idą w AVIF / WebP z srcset. Targi generują ciężkie JPEG ze stoiska; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk Packstation. Query Monitor na stagingu pokazuje, czy Germanized, wtyczka DHL i bramka nie dokładają po N zapytań na każdy request koszyka. HPOS zmniejsza ból list zamówień w panelu. Nie naprawia ciężkiego motywu na storefrontcie.

Pomiar: Lighthouse i dane terenowe na URL produktu, kategorii i checkoutu, przed i po. Jeśli po zmianie INP na checkoucie nadal blokuje skrypt Klarna, problemem jest kolejność ładowania, nie kolejna wtyczka “optymalizacyjna”.

Tydzień Messe to test infrastruktury, nie średnia z kwartału. Monitoring z jednego regionu USA kłamie, gdy goście stoją w kolejce przy bramie Nord. Punkt pomiaru w DE albo przynajmniej w UE jest częścią kryteriów odbioru. Przed LogiMAT i przed jesiennym cyklem targów idzie osobny przegląd limitów PHP, cache i kolejek Action Scheduler; po targach idzie ścinka landingów promocyjnych, które mają zostać jako archiwum, i tych, które mają dostać przekierowanie 301.

Dla serwisu B2B w Stuttgarcie liczy się też czas do pierwszego bajtu z sieci korporacyjnej w Zuffenhausen, Untertürkheim albo przy A8/A81, nie tylko z telefonu na Schlossplatz. Monitoring z jednego regionu USA kłamie podwójnie w tygodniu LogiMAT, bo sieć halowa i roaming gości z Azji i USA wyglądają inaczej niż CrUX z Baden-Württembergii.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe, kolejność metod płatności (i czy giropay nadal wisi), strefy DHL i Packstation, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, ścieżkę Widerruf, eksport DATEV albo jego brak, baseline Lighthouse, kalendarz Messe w harmonogramie wydań. Na tym etapie zapada, co jest źródłem stanu, podatku i numeru dokumentu.

Implementacja idzie gałęziami funkcyjnymi. Każda bramka ma scenariusz sandbox: PayPal, Klarna Playground, Stripe / Mollie test, Lastschrift tam gdzie PSP daje testowy mandat, Vorkasse jako ręczne przejście statusu. DHL ma środowisko testowe etykiet; etykieta z prawdziwym EKP na stagingu bez flagi testowej nadaje się do kłopotu. QA kończy się zamówieniem, które przechodzi: koszyk mieszany 19/7, Packstation z Postnummer, webhook, notatka w zamówieniu, etykieta, mail, a potem zwrot częściowy na tę samą bramkę.

Przekazanie to runbook bramek, mapa stref, opis Widerruf po stronie sklepu, instrukcja eksportu DATEV i zapis decyzji HPOS. Wycena jest indywidualna i na piśmie przed startem. Zmiany zakresu omawiamy z konsekwencją dla terminu. Nie publikujemy cennika SKU na tej stronie.

#Kiedy ta strona, a kiedy opieka albo programista WordPress

Ta strona zostaje przy sklepie: katalog, checkout, płatność, dostawa, stan, dokument, zwrot. Motyw bloga, Gutenberg, intranet albo strona korporacyjna centrali w Zuffenhausen nie są tutaj tematem - to programista WordPress w Stuttgarciu. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Stuttgarciu. Szerszy opis utrzymania bez miasta: utrzymanie stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

CARS 2.0 i ARENA2036 tłumaczą, skąd biorą się sklepy B2B z Vorkasse i DATEV. Nie tłumaczą, czemu Packstation bez Postnummer odrzuca etykietę. Transformations-Gipfel w październiku 2026 i Zulieferertag w Esslingen dokładają okna, w których checkout musi działać bez deployu w piątek wieczorem.

#Rozpocznij projekt sklepu WooCommerce w Stuttgarcie

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone, czy giropay nadal widać, skąd leci DHL (EKP, Packstation czy tylko drzwi), czy HPOS jest włączony, jaki jest magazyn (Esslingen, 3PL, centrala w Zuffenhausen), czy Steuerberater czeka na DATEV, czy Widerrufsbutton jest na produkcji po 19 czerwca 2026, i które daty Messe blokują wydanie. Na tej podstawie widać, czy potrzebna jest przebudowa checkoutu, czy zestawienie webhooków i stanów.

WPPoland pracuje przy WooCommerce od strony zamówienia, nie od strony slajdu. Stuttgart dostaje ten sam rygor inżynierski co każdy inny sklep, tylko ze stackiem, którego kupujący w Niemczech naprawdę używa, i z kalendarzem Messe wpisanym w harmonogram wydań.