Programista WooCommerce w Wiedniu

Sklep WooCommerce w Wiedniu konkuruje z kupującym, który płaci PayPalem albo Klarną, przelewa przez EPS-Überweisung z Erste albo Raiffeisen, odbiera w Abholstation przy Westbahnhof albo w Seestadt i oczekuje faktury z poprawnym USt, którą Steuerberater wczyta do BMD albo DATEV AT. Checkout skopiowany z innego rynku - karta na pierwszym miejscu, brak EPS, metody płatności, których austriacki bank już nie obsługuje - gubi zamówienia zanim ktokolwiek oceni motyw. Ta strona opisuje budowę i naprawę sklepu: katalog, checkout, płatności, dostawy, stany i zwroty. Nie opisuje opieki serwera ani motywu korporacyjnego bez koszyka.

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

#Checkout WooCommerce w Wiedniu

Wiedeń nie jest tylko Ringstraße i operą. Jest stolicą, w której łączą się turystyka, handel detaliczny, biotechnologia w Seestadt Aspern, UNO City i gęsta sieć marek D2C na Mariahilfer Straße. Według studii Handelsverbandu i KMU Forschung Austria z 2026 roku austriacki e-commerce osiąga około 12,3 mld EUR wydatków rocznie, a mobilny kanał odpowiada za około 44 procent tego wolumenu. Kupujący w Wiedniu oczekuje checkoutu, który działa na smartfonie w U-Bahn między Stephansplatz a Praterstern, nie tylko na biurowym laptopie w Innere Stadt. Jeśli checkout kłamie w podatku, w metodzie płatności albo w adresie Abholstation, reszta sklepu nie uratuje zamówienia.

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 Austrii w 2026

Austriacki koszyk nie zaczyna się od karty. PayPal pozostaje portfelem, którego kupujący szuka w pierwszym ekranie metod. Klarna AT pokrywa Kauf auf Rechnung, Pay Later i raty na wyższy koszyk, szczególnie przy odzieży, kosmetykach i elektronice D2C. EPS Online-Überweisung (Electronic Payment Standard przez STUZZA) to austriacki standard przelewu bankowego online: kupujący wybiera bank, loguje się w środowisku banku i autoryzuje płatność. Erste Bank, Raiffeisen, BAWAG P.S.K. i inne instytucje w Austrii obsługują EPS jako metodę, której brak na checkoucie odcina część kupujących starszej generacji i klientów B2B przy pierwszym zakupie.

Karta przez Stripe albo Mollie zostaje jako warstwa uniwersalna z PSD2, SCA i 3DS2. Apple Pay i Google Pay wchodzą jako warstwa karty na mobile, nie jako zamiennik PayPal. Vorkasse, czyli przelew z góry na IBAN sklepu w EUR, zostaje przy hurtcie, gastronomii i sklepach stacjonarnych w dzielnicach takich jak Neubau albo Leopoldstadt, których sklep nie wyśle, zanim księgowość zobaczy wpływ.

Kolejność metod na checkoucie ustawiamy pod ten mix: PayPal i Klarna AT wysoko, EPS tam gdzie PSP ma stabilną integrację STUZZA, karta niżej, Vorkasse tylko w ścieżce B2B. Domyślny szablon Woo z kartą na górze pracuje wbrew nawykom rynku austriackiego. Studia z 2026 roku pokazują, że ponad 70 procent austriackich kupujących online finalizuje transakcję na smartfonie; checkout, który wymaga pięciu ekranów i nie oferuje portfela, traci konwersję właśnie na mobile.

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 Donaustadt druga opcja chroni przed pobraniem pieniędzy za SKU, którego nie ma. EPS kończy się przelewem bankowym; sklep, który oznacza zamówienie jako completed w sekundę po przekierowaniu do banku, kłóci się z rzeczywistością księgową, dopóki webhook albo ręczna weryfikacja wpływu nie potwierdzi płatności.

#Strefy dostaw: Post AG, Abholstation i logistyka w aglomeracji

Krajowa dostawa z Austrii w 2026 to przede wszystkim Österreichische Post AG. Według danych branżowych Post obsługuje znaczną część przesyłek e-commerce w kraju, często podawaną jako około 38 do 52 procent w zależności od segmentu i źródła. Oficjalne rozwiązania Post AT dla biznesu obejmują Post Modul, integracje API i etykiety Paket. Konfiguracja biznesowa wymaga umowy Geschäftskunde i danych nadawcy zgodnych z kontraktem. Wtyczki WooCommerce dla Post AT mapują produkty (Paket, Kleinpaket, warianty międzynarodowe) do stref Woo.

Abholstation i Pick-up punkty Post są w Austrii automatem, którego checkout musi obsłużyć w polach adresu, a nie w notatce do zamówienia. W Wiedniu sieć jest gęsta: stacje przy Westbahnhof, w Seestadt, w Favoriten i przy Handelskai są codziennym wyborem najemców, którzy nie siedzą w domu na kuriera. Poprawny adres wymaga identyfikatora punktu odbioru zgodnego z API Post, kodu pocztowego stacji i kraju Austria. Ręczne wpisanie “Abholstation” w linii adresu bez identyfikatora kończy się odrzuceniem etykiety.

Magazyny w Donaustadt, Simmering albo w Fischamend mają inny rytm niż sklep z showroomem w Innere Stadt. Sklep z biurem przy Graben może obiecywać odbiór osobisty w godzinach biurowych, podczas gdy fulfillment z hali w Donaustadt wysyła paletami DPD albo GLS. Strefy Woo rozdzielamy więc nie tylko na “Austria / UE / reszta świata”, ale na wagę i wymiar: do progu Paket albo filia Post, powyżej kurier Post do drzwi albo DPD. Jedna stawka “darmowa dostawa AT” na wszystko psuje marżę na gabarycie i konwersję na drobnicy.

Messe Wien dokłada trzeci wymiar logistyki dla wystawców i marek towarzyszących. Przy montażu stoiska na targach branżowych dostawy ciężarówek na teren Messeplatz wymagają slotów czasowych i koordynacji z organizatorem. To nie jest konfiguracja Woo, ale wpływa na sklep, który sprzedaje materiały montażowe, sprzęt AV albo catering dla wystawców: cutoff nadania w tygodniu przed otwarciem hal musi być w runbooku operacyjnym, a nie w nagłówku marketingowym.

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 API Post policzy routing. Ręczne klejenie etykiet w portalu Post przy skoku po świętach albo przed dużymi targami nie skaluje się.

DHL Austria, GLS i DPD uzupełniają Post tam, gdzie gabaryt, B2B same-day w aglomeracji albo wysyłka międzynarodowa wymaga innego kontraktu. Wybór przewoźnika zapisujemy w runbooku per strefa, nie jako jedna wtyczka “dostawa”.

#USt, OSS i pole UID

Stawki krajowe w Austrii w 2026 pozostają 20 procent (reguła), 13 procent (m.in. zakwaterowanie i wydarzenia kulturalne) i 10 procent (żywność i wybrane usługi). Koszyk mieszany jest codziennością przy sklepie, który sprzedaje merchandising obok książki kucharskiej albo zestawu kawy obok kubka. 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 do księgowości.

Sprzedaż B2C do innych krajów UE po przekroczeniu unijnego progu OSS idzie stawką kraju destynacji, nie austriackim 20 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. Marka z Wiednia, która “na razie sprzedaje tylko do AT”, przekracza próg ciszej niż zakłada, bo Wiedeń ma duży odsetek zamówień od ekspatów i gości targowych z adresem w innym kraju UE.

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

Granicę “co liczy podatek i wystawia dokument” zapisujemy w runbooku: wtyczka fakturowa 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 austriackie wymogi dokumentacji księgowej tego nie wybaczają.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Wiedniu, 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 Donaustadt, 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 U-Bahn między Karlsplatz a Landstraße, traci sieć w tunelu, 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 Post AG - 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.

#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 produktu przed świętami 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, Zalando 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 Erste albo Raiffeisen potrzebuje czasu na księgowanie. 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 do księgowości i gubi zwroty. Oficjalne integracje Post, PayPal Payments, Stripe i Mollie są na HPOS od dawna. Problemem są stare konektory magazynowe, wtyczki subskrypcji sprzed kilku majorów 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 Wiedniu albo w 3PL w Donaustadt widziała tę samą historię co programista.

#Faktury, DSGVO i eksport do księgowości

Sklep w Wiedniu rzadko jest systemem księgowym. Jest źródłem zdarzeń sprzedaży, które Steuerberater ma wciągnąć do BMD, RZL albo DATEV AT. Austriackie wymogi dokumentacji wymagają kolejnych numerów dokumentów, ścieżki audytu i zgodności z DSGVO oraz austriackim DSG. 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 do księgowości w praktyce to plik CSV albo format wymagany przez wybrany system plus paczka PDF. Mapowanie kont uzgadniamy ze Steuerberaterem: osobne konta przychodu dla 20, 13 i 10 procent USt, osobne dla dostaw wewnątrzwspólnotowych, osobne konta przejściowe per bramka (PayPal, Klarna, Stripe, Mollie, bank przy Vorkasse i EPS), 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 zwrotów po świętach już zdążył odwrócić marżę miesiąca.

Przed dostępem agencji do panelu sklepu z danymi klientów regulowanych branż wymagana jest umowa powierzenia przetwarzania (Auftragsverarbeitungsvertrag, AVV) zgodnie z art. 28 DSGVO i §29 austriackiego DSG. To nie jest formalność prawnicza: bez AVV hosting, bramka płatnicza i narzędzie analityczne nie mogą legalnie przetwarzać danych zamówień. Zgoda cookie w Austrii podlega interpretacji Datenschutzbehörde i RTR; skrypt analityczny ładowany przed zgodą to ryzyko, które leży poza Woo, ale checkout musi respektować decyzję użytkownika przy remarketingu koszyka.

Gewerbeordnung (ustawa o działalności gospodarczej) wymaga, żeby sklep internetowy z siedzibą w Austrii miał widoczne dane firmy (Impressum), informacje o prawie odstąpienia i regulamin. Woo dostarcza mechanizm treści (strony informacyjne, linki w stopce), ale teksty zatwierdza kancelaria albo odpowiedzialny w firmie. Zadaniem programisty jest spiąć te strony z checkoutem, z mailem transakcyjnym i z polami wymaganymi prawnie, nie pisać porady prawnej w komentarzu PHP.

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

#Zwroty i Fernabsatz jako operacje sklepu

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

Konsument w Austrii ma 14 dni na odstąpienie od umowy zawartej na odległość na podstawie FAGG (Fernabsatz- und Auslieferungsgesetz). Termin zaczyna biec, gdy informacja o prawie odstąpienia została udzielona poprawnie. Brak albo błąd informacji wydłuża okno. Dla magazynu w Donaustadt to nie ciekawostka prawna. To SKU, którego nie wolno sprzedać drugi raz, bo może wrócić za trzy kwartały.

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

1. Klient składa odstąpienie 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ą Post 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ęściowe odstąpienie (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 prawa odstąpienia (higiena, personalizacja, treść cyfrowa po rozpoczęciu, żywność z krótkim terminem) musi mieć tę informację przy SKU przed zakupem. Checkout, który o tym milczy, spycha spór na obsługę.

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

Sezon po Bożym Narodzeniu i po letnich wyprzedażach 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 księgowość i nadsprzedaje wracający towar. Przy odzieży D2C model zwrotów trzeba założyć w holdach magazynu od pierwszego SKU, nie po pierwszym sporze. Studia KMU Forschung Austria z 2026 wskazują, że ponad połowa austriackich kupujących online złożyła co najmniej jeden zwrot w ciągu roku; odzież napędza tę statystykę najmocniej.

#Katalog i checkout pod marki z Wiednia

Wiedeń ma własny rytm sprzedaży, który nie jest kopią Monachium ani Zurychu. Turystyka, sezon świąteczny na Graben, targi w Messe Wien i gęstość ekspatów dzielnicach takich jak Leopoldstadt dokładają skoki ruchu na sklepach z merchandisingiem, kosmetykami, żywnością specjalistyczną i elektroniką D2C. Sklep, który w tych tygodniach wgrywa nową wtyczkę płatności albo przełącza HPOS na produkcji, ryzykuje utratę zamówień w szczycie, który planował przez rok.

Katalog, który przez jedenaście miesięcy ma kilkaset pozycji, przed sezonem dostaje warstwę limitowanych zestawów, cen obowiązujących “do wyczerpania zapasu” i wariantów, których nie ma w stałej ofercie. Woo musi to udźwignąć bez zgonu strony kategorii. Warianty trzymamy jako prawdziwe variation z własnym SKU, wagą i klasą podatkową, nie jako pole tekstowe “wpisz kolor”. Duża macierz (rozmiar × wzor × edycja limitowana) dostaje własne zapytania i cache fragmentów.

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

Subskrypcja nie jest wtyczką “włącz i zapomnij”. Cykl, mandat płatności cyklicznej, skip shipment, zmiana SKU w trwającej umowie i odstąpienie od pierwszej dostawy to cztery osobne ścieżki. Woo Subscriptions albo własna warstwa muszą pisać do tych samych tabel HPOS co zamówienie jednorazowe. Osobna tabela “subskrypcje w postmeta” przy włączonym HPOS kończy się raportem, którego księgowość nie przyjmie.

Ceny netto / brutto na checkoucie B2B (netto plus USt) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z UID w UNO City oczekuje netto. Konsument z Neubau 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 Wiedniu często idzie po niemiecku austriackim (DE-AT) jako kanon, z angielskim dla gości targowych i ekspatów. Formy takie jak Jänner zamiast Januar, Feber zamiast Februar, Erdäpfel zamiast Kartoffel sygnalizują lokalność i budują zaufanie w turystyce i handlu detalicznym. WPML WooCommerce Multilingual albo Polylang nie mogą rozjechać klas podatkowych i metod dostaw między językami. Tłumaczenie nazwy metody “Post Abholstation” nie może stworzyć drugiej, nieprzypiętej metody w strefie. Angielski checkout, który zostawia informację o odstąpieniu tylko po niemiecku, spycha spór na mail, którego sklep nie wygra.

#Kalendarz freeze: kiedy checkoutu nie ruszamy

Daty szczytu (święta, duże targi w Messe Wien, sezon turystyczny na Mariahilfer) wpisujemy w runbook wydań, nie w hardcoded stringu w motywie. Na produkcję nie wchodzi w tych oknach: nowa bramka płatnicza, przełączenie HPOS, zmiana stref Post, aktualizacja wtyczki fakturowej, która dotyka numeracji dokumentów. Łatka bezpieczeństwa, która nie może czekać, idzie przez środowisko testowe w godzinach, nie w nocy przed otwarciem hal.

Sklep, który sprzedaje w czasie festiwali i eventów Prater albo przy Rathausplatz, dostaje drugi wektor ruchu mobilnego. Checkout musi działać na LTE w centrum, a webhooki muszą przeżyć timeouty sieci. Freeze operatorski i dyżur alertów są wtedy ważniejsze niż nowa wtyczka newslettera.

#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 Post ł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. Sezonowe dropy generują ciężkie JPEG ze studia; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk Abholstation. Query Monitor na stagingu pokazuje, czy wtyczka fakturowa, integracja Post 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 ogólna “optymalizacja”. Mobile-first nie jest sloganem w Austrii: według badań branżowych z 2026 około 44 procent wydatków e-commerce idzie przez smartfony i tablety, a około 71 procent kupujących finalizuje zakup na urządzeniu mobilnym.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe USt, kolejność metod płatności (EPS, PayPal, Klarna AT), strefy Post/DPD/GLS, Abholstation i identyfikatory punktów, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, ścieżkę odstąpienia Fernabsatz, eksport do księgowości albo jego brak, baseline Lighthouse, kalendarz sezonowy Wiednia. 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, EPS tam gdzie PSP daje środowisko testowe, Vorkasse jako ręczne przejście statusu. Post ma środowisko testowe etykiet; etykieta z prawdziwym kontraktem na stagingu bez flagi testowej nadaje się do kłopotu. QA kończy się zamówieniem, które przechodzi: koszyk mieszany 20/10/13, Abholstation z poprawnym identyfikatorem, webhook, notatka w zamówieniu, etykieta, mail, a potem zwrot częściowy na tę samą bramkę.

Przekazanie to runbook bramek, mapa stref, opis odstąpienia po stronie sklepu, instrukcja eksportu do księgowości, zapis decyzji HPOS i kalendarz freeze. Wycena jest indywidualna i na piśmie przed startem. Zmiany zakresu omawiamy z konsekwencją dla terminu. Nie publikujemy cennika SKU na tej stronie.

Filary oferty, gdy zakres wychodzi poza ten audyt: programista WordPress w Wiedniu przy stronie bez koszyka, opieka techniczna WordPress w Wiedniu przy stałej opiece bez przebudowy checkoutu.

#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 z Innere Stadt bez koszyka nie są tutaj tematem - to programista WordPress w Wiedniu. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Wiedniu. Wspólny filar e-commerce: programista WooCommerce.

Austriacki rynek e-commerce w 2026 stoi przed podwójną presją: mobilna wygoda checkoutu i konkurencja zagranicznych platform, na które według Handelsverbandu idzie około 47 procent wydatków online. Lokalny sklep WooCommerce w Wiedniu wygrywa wtedy, gdy oferuje EPS, Klarnę, Post AG i przejrzyste USt lepiej niż marketplace z Chin, a nie wtedy, gdy ma ładniejszy slider na stronie głównej. WooCommerce pozostaje dominującą platformą sklepów Austrii (szacunki branżowe podają około 30 do 42 procent udziału wśród platform e-commerce), więc naprawa checkoutu ma sens ekonomiczny, zanim firma przenosi katalog na inną platformę.

WordPress Meetup Vienna i ekosystem startupów Seestadt są lokalnym punktem odniesienia dla społeczności, nie zamiennikiem audytu checkoutu. Gęstość marek D2C na Mariahilfer i w dzielnicach modowych tłumaczy, skąd biorą się sklepy z wysokim udziałem Klarny i zwrotów przy odzieży. Nie tłumaczą, czemu Abholstation bez identyfikatora punktu odrzuca etykietę.

#Rozpocznij projekt sklepu WooCommerce w Wiedniu

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone, czy EPS jest na checkoucie, skąd leci Post (kontrakt Geschäftskunde, Abholstation czy tylko drzwi), czy HPOS jest włączony, jaki jest magazyn (Donaustadt, Favoriten, Seestadt, 3PL), czy Steuerberater czeka na eksport do BMD albo DATEV AT, czy informacja o prawie odstąpienia jest poprawnie podpięta do checkoutu, oraz czy w kalendarzu jest sezon targowy albo świąteczny szczyt. 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. Wiedeń dostaje ten sam rygor inżynierski co każdy inny sklep austriacki, tylko ze stackiem płatności, logistyki Post AG i kalendarzem lokalnym, których kupujący w aglomeracji wiedeńskiej naprawdę używa.