Programista WooCommerce w Genewie

Sklep WooCommerce w Genewie konkuruje z kupującym, który płaci TWINT-em albo PostFinance, oczekuje faktury z MWST i kodem QR-Rechnung, który bank przyjmie z adresem strukturalnym, i chce Track & Trace od Post CH, nie numeru z polskiego kuriera. Checkout skopiowany z rynku euro albo z RFN - karta na pierwszym miejscu, niemiecki MwSt, brak TWINT - gubi zamówienia zanim ktokolwiek oceni motyw. Ta strona opisuje budowę i naprawę sklepu: katalog, checkout, płatności, dostawy, stany i dokumenty. Nie opisuje opieki serwera ani motywu korporacyjnego bez koszyka.

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

#Checkout WooCommerce w Genewie

Genewa jest drugim co do wielkości miastem Szwajcarii i jednym z najgęstszych węzłów dyplomacji oraz finansów Europie. Palais des Nations, WTO przy rue de Lausanne, Rive, Carouge i Geneva Digital Hub w Plan-les-Ouates to nie lista klientów. To kontekst, w którym sklep B2C z koszykiem w CHF musi wyglądać jak lokalny handel, a nie jak tłumaczenie sklepu z euro strefy. Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż detaliczną z dostawą PostPac do kodów 1201, 1202 albo 1204 oraz skoki katalogu przed sezonem prezentowym albo przed szczytem WTO, gdy magazyn w Meyrin albo w Satigny musi wyjechać paletą Swiss-Express, a nie listem A+.

Oba rytmy kończą się w tym samym checkoucie. Jeśli checkout kłamie w podatku MWST, w metodzie płatności albo w zaokrągleniu brutto do 5 Rappen, 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 Szwajcarii w 2026

Szwajcarski koszyk nie zaczyna się od karty Visa. TWINT jest portfelem, którego kupujący szuka w pierwszym ekranie metod. Oficjalna wtyczka TWINT-AG dla WooCommerce (PHP 8.1+, rozszerzenie soap, certyfikat .p12, PHP CLI dla procesów tle) obsługuje Regular Checkout i Express Checkout. Brak CLI na serwerze kończy się ostrzeżeniem w panelu i martwymi webhookami. PostFinance Checkout (wtyczka woo-postfinance-checkout w repozytorium WordPress) agreguje TWINT, PostFinance Pay, Visa, Mastercard, American Express, Apple Pay, Click to Pay, fakturę (Purchase by invoice), eBill i przelew z góry w jednym kontrakcie z PostFinance. Konfiguracja wymaga Space ID, User ID i Authentication Key z portalu Checkout; aktywacja subskrypcji u acquirera trwa zwykle jeden do dwóch dni roboczych.

datatrans działa jako PSP trzeciej strony, gdy sklep potrzebuje jednego API pod kartę, TWINT i portfele bez wiązania się wyłącznie z PostFinance. Stripe w Szwajcarii obsługuje karty i Apple Pay, ale nie zastąpi TWINT w oczach lokalnego kupującego. PayPal nadal jest warstwą uniwersalna dla klientów zagranicznych i dla ekspatów przy Quai du Mont-Blanc. Kauf auf Rechnung przez Powerpay albo Klarna wchodzi tam, gdzie koszyk przekracza próg zaufania i gdzie fiduciar akceptuje ryzyko niewypłacalności.

Kolejność metod na checkoucie ustawiamy pod ten mix: TWINT i PostFinance Pay wysoko, Apple Pay obok, karta niżej, PayPal dla ruchu spoza CH, faktura tylko w ścieżce B2B z limitem kredytowym. Domyślny szablon Woo z kartą na górze pracuje wbrew nawykom rynku genewskiego. Polski runbook z BLIK, Przelewy24 albo InPost nie przenosi się do Genewy. W Genewie obowiązuje TWINT, PostFinance, MWST i QR-Rechnung, nie KSeF ani Allegro.

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. PostFinance Checkout zgłasza capture i odmowę osobnymi zdarzeniami; w wersji 3.4.x (2026) testowano m.in. WooCommerce 10.8.x i PHP 8.2. TWINT wymaga osobnej ścieżki Express Checkout z konfiguracją ekranów wyświetlania przycisku. Faktura z góry albo eBill to osobny flow: zamówienie nie może iść na processing, zanim księgowość zobaczy wpływ na koncie PostFinance albo w camt.053.

#Strefy dostaw: Post CH, walidacja adresu i Swiss-Express

Krajowa dostawa z Szwajcarii w 2026 to przede wszystkim Post CH (Schweizerische Post). Oficjalna wtyczka Swiss Post: Barcodes, Address Checker & Auto-Complete (rynek WooCommerce) wymaga kontraktu biznesowego, Client Identifier i Client Secret z Digital Commerce API, oraz licencji frankingu (franking license). Od czerwca 2023 domyślny endpoint to DCAPI zamiast WEDEC. Wtyczka generuje etykiety z kodem kreskowym Post CH, Track & Trace i opcjonalnym mailem statusu (SMS Post CH nie jest już wspierany).

Auto-complete i Address Checker na checkoucie podpowiadają ulicę, kod i miejscowość według bazy Post CH. Klient może nadal wysłać adres niewalidowany, ale walidacja zmniejsza błędy typu „1201 Genève” bez numeru domu albo „Rue du Rhône” bez numeru lokalu. Dla sklepu w Rive błąd adresu kończy się zwrotem paczki do magazynu w Meyrin i kosztem obsługi, którego marża na kosmetyku z Carouge nie pokrywa.

Strefy Woo rozdzielamy na produkty PostPac Economy, PostPac Priority, Bulky Goods, Swiss-Express Moon i Saturday Delivery tam, gdzie kontrakt Post CH to przewiduje. Gabaryt nie wchodzi do skrytki pocztowej tak jak mała paczka. Odbiór osobisty w Genewie (Filiale, nie Packstation w niemieckim sensie) ma osobną metodę z adresem punktu. Jedna stawka „darmowa dostawa CH” na wszystko psuje marżę na winie z Lavaux albo na meblu wysyłanym Bulky Goods.

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 TWINT oddał 200 zanim API Post CH policzy routing. Ręczne klejenie etykiet w portalu Post CH przy liczbie zamówień po weekendzie zakupowym przy Rive nie skaluje się.

#MWST, CHF i QR-Rechnung

Ta strona nie publikuje cen WPPoland. Opisuje, jak podatek szwajcarski ma wyglądać w sklepie, nie w cenniku agencji. MWST (Mehrwertsteuer / TVA) to szwajcarski podatek od wartości dodanej, nie niemiecki MwSt. Od 1 stycznia 2024, bez zmiany na 2026, obowiązują trzy stawki ESTV: 8,1% (Normalsatz), 2,6% (redukowana: m.in. żywność, książki, leki) i 3,8% (Beherbergung). Próg rejestracji: obrót 100 000 CHF. Numer na fakturze: CHE-xxx.xxx.xxx MWST. Kwota brutto zaokrąglana do 5 Rappen (0,05 CHF), nie do 10 groszy ani do jednego centa euro.

Koszyk mieszany jest codziennością przy sklepie, który sprzedaje książkę obok elektroniki albo zestaw prezentowy obok żywności ze stawką obniżoną. Woo musi liczyć podatek per pozycja, a nie „weź najwyższą stawkę koszyka”. Błąd w klasie podatkowej produktu wychodzi dopiero na PDF z QR-Rechnung i w eksporcie do fiduciar. Sklep, który po aktualizacji wtyczki fakturującej gubi UID albo zaokrąglenie, produkuje dokumenty, których księgowość w Genewie nie przyjmie.

QR-Rechnung (QR-bill) zastąpiła stare Einzahlungsscheine. W Swiss QR Code od 21 listopada 2025 ma być adres strukturalny (Adresstyp S): ulica, numer, kod, miejscowość, kraj w osobnych polach, nie jedna linia „Rue du Rhône 1, 1204 Genève” w polu typu K. Okno przejściowe zamyka się w 2026: banki zapowiadają kategoryczne odrzucanie nieustrukturyzowanych adresów. Checkout, który generuje kod z adresem typu K, kończy się tym, że klient „zapłacił” TWINT-em, a faktura QR nie przechodzi w eBankingu.

Granicę „co liczy podatek i wystawia dokument” zapisujemy w runbooku: wtyczka faktur w Woo, osobny silnik QR-Rechnung, albo ERP jako źródło prawdy. Jedno źródło numeracji. Dwa źródła dają podwójne numery albo dziury, a fiduciar tego nie wybacza. Waluta sklepu to CHF. Wyświetlanie EUR „dla wygody” bez jawnej stopy i bez zgody klienta to osobna decyzja compliance, nie przełącznik w motywie.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Genewie, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu „Zapłać TWINT-em”. Sklep z magazynem w Meyrin, 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. Klient po autoryzacji TWINT zamyka kartę w tramwaju przy Cornavin, 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 QR-Rechnung, nadanie Post CH - zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i PostFinance albo TWINT nie zaczęły ponawiać webhooka.

Powtórzony sygnał z bramki jest normą, nie awarią. 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. 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. Zwrot częściowy idzie przez wc_create_refund z listą pozycji i kwot oraz z flagą zwrotu na bramce TWINT albo PostFinance. Traktowanie każdego zwrotu jak pełnego anulowania psuje raport sprzedaży i stany po sezonie świątecznym.

#Rezerwacja magazynu i sprzedaż wielokanałowa

Stan rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce 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 TWINT na ostatnią sztukę SKU z półki w Plan-les-Ouates i oboje dostaje potwierdzenie. Faktyczne odjęcie stanu robi wc_maybe_reduce_stock_levels i pilnuje go flaga _order_stock_reduced.

Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o Galaxus, Ricardo ani innym kanale. Źródłem prawdy zostaje wspólna pula w ERP albo w warstwie fulfilment, a Woo trzyma stan przez synchronizację. Hold stock przy fakturze z góry ustawia się dłużej niż przy TWINT: przelew QR-Rechnung potrafi iść do następnego dnia roboczego. Zbyt krótki hold zdejmuje rezerwację, zanim księgowość zaksięguje wpływ.

#Tabele wp_wc_orders i tryb zgodności

High-Performance Order Storage jest domyślny dla nowych instalacji od WooCommerce 8.2. 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, potem HPOS jako magazyn autorytatywny, na końcu wyłączenie dual-write gdy raporty i wtyczki przestaną się rozjeżdżać.

Diagnostyka idzie 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 PostFinance Checkout, TWINT, Swiss Post i Stripe 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 TWINT, zanim produkcja dostanie przełączenie.

Log ma pozwolić odtworzyć historię zamówienia bez logowania do panelu PostFinance. Do dziennika przez wc_get_logger trafia identyfikator zdarzenia, status przed i po, kwota w CHF, wynik weryfikacji sygnatury i decyzja (przetworzono albo pominięto jako duplikat). Nie trafia pełny payload z danymi płatniczymi. Retencja logów uzgadniana jest z polityką nDSG klienta, nie „kasuj po siedmiu dniach” domyślnie z wtyczki debug.

#nDSG, hosting w CH i impressum

Sklep w Genewie zbiera dane osobowe: adres dostawy, e-mail, telefon, czasem datę urodzenia przy winie z Lavaux. Zrewidowana federalna ustawa o ochronie danych (nDSG, weszła 1 września 2023) wymaga informacji o administratorze, celu, odbiorcach i transferze za granicę w Politique de confidentialité. EDÖB (FDPIC) nadzoruje compliance. Naruszenie z „likely high risk” zgłasza administrator przez portal DataBreach. Agencja WooCommerce nie składa zgłoszenia za klienta. Dostarcza oś czasu techniczną.

Hosting w CH (Infomaniak z Genewy, Cyon, Metanet, Hostpoint) to decyzja, która wpada na kick-offie obok TWINT, nie w stopce marketingowej. Origin w Szwajcarii skraca drogę do użytkownika i do sieci, które i tak peerują lokalnie. Kopia nocą poza CH wymaga ujawnienia w polityce prywatności. CDN kończący TLS w USA bez świadomej zgody klienta odpada na pierwszej rozmowie z IT firmy przy Quai du Mont-Blanc.

Impressum i UID muszą zgadzać się z Zefix i z Registre du commerce du canton de Genève. Francuski szwajcarski (fr-CH): septante/nonante w niektórych kontekstach, MWST/TVA zgodna z ESTV, adresy w formacie szwajcarskim. Szablon impressum skopiowany z francuskiej SAS (RCS Paris, SIRET) na stronie genewskiej SA albo Sàrl jest błędem, który prawnik klienta zobaczy szybciej niż wynik Lighthouse. Checkout w dwóch językach (fr/en) przez WPML albo Polylang nie może rozjechać klas podatkowych i metod Post CH między wersjami językowymi.

#Katalog i checkout pod rynek genewski

Banque Cantonale de Genève (BCGE) i szerszy ekosystem private banking w kantonie ustawiają poprzeczkę inaczej niż sklep szablonowy. To nie znaczy, że każdy sklep musi wyglądać jak bank. Znaczy, że kupujący oczekuje spójności: CHF na etykiecie, TWINT w pierwszym rzędzie, QR-Rechnung który przechodzi, Track & Trace Post CH w mailu transakcyjnym.

Warianty trzymamy jako prawdziwe variation z własnym SKU, wagą i klasą podatkową MWST, nie jako pole tekstowe „wpisz kolor”. Duża macierz (rozmiar × materiał × wykończenie) dostaje własne zapytania i cache fragmentów. Filtrowanie, 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 sezonem prezentowym: SKU jest widoczny, płatność schodzi TWINT-em, ale fulfillment stoi aż do daty. Status on-hold albo własny status „warte na magazyn” musi blokować etykietę Post CH. Inaczej wtyczka Swiss Post nada paczkę, której jeszcze nie ma w Meyrin. Ceny netto / brutto na checkoucie B2B (netto plus MWST) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z UID w Lausanne oczekuje netto. Konsument z Carouge oczekuje brutto w CHF z zaokrągleniem 5 Rappen.

#Dwujęzyczność francusko-angielska na checkoucie

W Genewie dominuje francuski CH, a angielski jest językiem operacyjnym w wielu organizacjach międzynarodowych, fundacjach i firmach exportowych. WordPress z WPML, Polylang albo TranslatePress wymaga regresji na obu locale po każdej aktualizacji: slugi, hreflang, menu, widgety, stringi w motywie, PDF-y do pobrania, meta SEO. Błąd klasyczny: patch wtyczki tłumaczeń nadpisuje .mo i angielska wersja checkout wraca francuskim tekstem „Paiement” bez crashu PHP.

Francuski szwajcarski nie jest francuskim z Paryża. W tekstach urzędowych i na stronie: terminologia podatkowa MWST/TVA zgodna z ESTV, adresy w formacie szwajcarskim. Szablon impressum skopiowany z francuskiej SAS (RCS Paris, SIRET) na stronie genewskiej SA albo Sàrl jest błędem, który prawnik klienta zobaczy szybciej niż Lighthouse. Checkout w dwóch językach nie może rozjechać klas podatkowych i metod Post CH między wersjami językowymi.

#Okna zamrożenia WTO, ONZ i sezon dyplomatyczny

W Genewie kalendarz polityczny wpływa na IT bardziej niż w typowym mieście usługowym. Ministerial Conference WTO, sesje Rady Bezpieczeństwa ONZ, World Economic Forum w Davos (dojazd z Genewy w godzinę) i szczyty humanitarne: wiele organizacji wprowadza freeze window, w którym zakazane są wdrożenia produkcyjne poza hotfixami bezpieczeństwa. Runbook sklepu dla Genewy powinien więc zawierać sekcję freeze: daty uzgodnione z klientem, wyjątki (CVE krytyczne), kto zatwierdza hotfix w weekend. Aktualizacja wtyczki checkoutu w tygodniu ministerial WTO to ryzyko, którego środowisko testowe ma zatrzymać przed produkcją.

#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ę. Skrypty TWINT, PostFinance i Swiss Post Address Checker ł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. Bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk TWINT Express. Query Monitor na stagingu pokazuje, czy wtyczka faktur, Swiss 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. Origin w CH plus sensowny motyw daje przewagę na Core Web Vitals w kraju, gdzie lokalne CDN są normą, nie luksusem. Dla sklepu B2B albo instytucjonalnego w Genewie liczy się też czas do pierwszego bajtu z sieci korporacyjnej w CH, nie tylko z telefonu nad Jeziorem Genewskim.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe MWST, kolejność metod płatności (i czy TWINT Express w ogóle działa na PHP CLI), strefy Post CH i walidację adresu, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, QR-Rechnung Adresstyp S, baseline Lighthouse. 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: PostFinance Checkout test, TWINT sandbox z certyfikatem, Stripe test tam gdzie karta jest aktywna. Swiss Post wymaga credentials DCAPI; etykieta z prawdziwym franking license na stagingu bez flagi testowej nadaje się do kłopotu. QA kończy się zamówieniem, które przechodzi: koszyk mieszany 8,1% / 2,6%, płatność TWINT, webhook, notatka w zamówieniu, etykieta PostPac, mail z Track & Trace, PDF z CHE-… MWST i QR typu S, a potem zwrot częściowy na tę samą bramkę.

Przekazanie to runbook bramek, mapa stref Post CH, opis zaokrąglenia 5 Rappen, instrukcja QR-Rechnung 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 bez koszyka nie są tutaj tematem - to programista WordPress oraz programista WordPress w Genewie. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Genewie i szerszy filar utrzymania stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

#Przypadek: aktualizacja wtyczki przed produkcją zatrzymała QR-Rechnung

Sklep WooCommerce obsługiwany przez polski zespół, sprzedaż do klientów Szwajcarii, stawki MWST 8,1%, UID na PDF, bramka z TWINT i z QR-Rechnung. W kolejce do produkcji leżała aktualizacja wtyczki fakturującej plus patch PostFinance Checkout. W kalendarzu klienta leżał tydzień ministerial WTO; freeze window obejmował wszystko poza CVE krytyczne.

Na środowisku testowym generator QR sypał kod z adresem typu K: cała linia „Rue du Rhône 1, 1204 Genève” w jednym polu. Po stronie banku taki kod po zamknięciu okna przejściowego w 2026 nie przechodzi. Równolegle TWINT wracał webhookiem, którego nowa wersja bramki mapowała na zły status zamówienia. Na produkcji ten sam zestaw poszedłby w piątkowe popołudnie genewskie. Magazyn dostałby zamówienia w pending, księgowość dostałaby dziurę w numeracji QR, a support dostałby kolejkę „zapłaciłem TWINT-em i nic”.

środowisko testowe zatrzymał promocję. Checklista checkoutu (koszyk, TWINT sandbox, PostFinance test, PDF z CHE-… MWST, QR z polami S, etykieta Post CH) przeszła, dopiero potem produkcja - po zakończeniu freeze window, w uzgodnionym oknie. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem kalendarz, potem produkcja.

#Rozpocznij projekt sklepu WooCommerce w Genewie

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone (TWINT, PostFinance, datatrans), czy QR-Rechnung ma Adresstyp S, skąd leci Post CH (DCAPI, PostPac czy Swiss-Express), czy HPOS jest włączony, gdzie stoi hosting (CH czy poza), jaki jest magazyn (Meyrin, Satigny, 3PL) i czy fiduciar czeka na poprawne MWST na fakturze. 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. Genewa dostaje ten sam rygor inżynierski co każdy inny sklep, tylko ze stackiem, którego kupujący w Szwajcarii naprawdę używa: CHF, TWINT, PostFinance, MWST, QR-Rechnung i Post CH.