Programista WooCommerce w Bernie

Sklep WooCommerce w Bernie 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 Bernie. Sklep już na produkcji, który potrzebuje aktualizacji i kopii, a nie przebudowy checkoutu, idzie na opiekę techniczną WordPress w Bernie.

#Checkout WooCommerce w Bernie

Berno to stolica federacyjna Szwajcarii i siedziba administracji federalnej przy Bundesplatz. Bern Digital Hub, Swisscom w Ittigen i ekosystem usług profesjonalnych wokół Bundeshaus ustawiają poprzeczkę inaczej niż szablon sklepu z motywu premium. Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż detaliczną z dostawą PostPac do kodów 3000, 3001 albo 3011 oraz skoki katalogu przed BEA Bern albo przed sezonem prezentowym, gdy magazyn w Ostermundigen albo Wankdorf 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 pracujących przy Bundeshaus. Kauf auf Rechnung przez Powerpay albo Klarna wchodzi tam, gdzie koszyk przekracza próg zaufania i gdzie Treuhänder 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 bernskiego. Polski runbook z BLIK, Przelewy24 albo InPost nie przenosi się do Berna. W Bernie 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. 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 „3000 Bern” bez numeru domu albo „Spitalgasse” bez numeru lokalu. Dla sklepu w Starej Mieście błąd adresu kończy się zwrotem paczki do magazynu w Ostermundigen i kosztem obsługi, którego marża na produkcie regionalnym 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 Bernie (Filiale, nie Packstation w niemieckim sensie) ma osobną metodę z adresem punktu. Jedna stawka „darmowa dostawa CH” na wszystko psuje marżę na winie z Berner Jura 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 w centrum Berna 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) 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 Treuhändera. Sklep, który po aktualizacji wtyczki fakturującej gubi UID albo zaokrąglenie, produkuje dokumenty, których księgowość w Bernie 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 „Bundesgasse 1, 3005 Bern” 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 Treuhänder 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 Bernie, 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 Ostermundigen, 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 Bundesplatz, traci sieć w tunelu przy Bern Hauptbahnhof, 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 Wankdorf 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 Bernie zbiera dane osobowe: adres dostawy, e-mail, telefon, czasem datę urodzenia przy winie z Berner Jura. Zrewidowana federalna ustawa o ochronie danych (nDSG, weszła 1 września 2023) wymaga informacji o administratorze, celu, odbiorcach i transferze za granicę w Datenschutzerklärung. 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, 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 SwissIX. 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 Bundesplatz.

Impressum i UID muszą zgadzać się z Zefix i z Handelsregisteramt des Kantons Bern. Niemiecki szwajcarski (de-CH): ss zamiast ß (Strasse), MWST zamiast MwSt. Szablon impressum skopiowany z niemieckiej GmbH z USt-IdNr i § 5 TMG na stronie bernskiej AG jest błędem, który prawnik klienta zobaczy szybciej niż wynik Lighthouse. Checkout w trzech językach urzędowych (de, fr, it) przez WPML albo Polylang nie może rozjechać klas podatkowych i metod Post CH między wersjami językowymi. W Bernie bliskość kantonu Fryburg i ruch francuskojęzyczny wymagają spójności etykiet podatkowych także w wersji fr-CH.

#Katalog i checkout pod rynek bernski

Bern Digital Hub, Swisscom w Ittigen i klastry usług profesjonalnych wokół administracji federalnej ustawiają poprzeczkę inaczej niż sklep szablonowy. To nie znaczy, że każdy sklep musi wyglądać jak portal urzędu. 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 BEA Bern albo 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 Ostermundigen. Ceny netto / brutto na checkoucie B2B (netto plus MWST) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z UID w Biel/Bienne oczekuje netto. Konsument z Bümpliz oczekuje brutto w CHF z zaokrągleniem 5 Rappen.

Sklepy obsługujące instytucje federalne albo dostawców administracji często wymagają numeru zamówienia publicznego, osobnej ścieżki faktury z góry i archiwum dokumentów zgodnego z wymaganiami działu zakupów. To nie jest moduł z motywu. To warstwa w własnej wtyczce z hookiem na woocommerce_checkout_order_processed i osobnym statusem „oczekuje na PO”.

#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. Sklep z magazynem w Wankdorf i klientami w całej Szwajcarii nie musi być w Zurychu, żeby checkout był szybki. Musi być poprawnie skonfigurowany.

#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 Bernie. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Bernie i szerszy filar utrzymania stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

WP Bern (wpbern.ch) jest lokalnym punktem odniesienia dla ekosystemu WordPress, nie zamiennikiem audytu checkoutu. Sesje o nDSG, hostingu w CH i consent w 2025-2026 tłumaczą, skąd biorą się wymagania klientów bernskich. Nie tłumaczą, czemu QR-Rechnung z adresem typu K odrzuca bank.

#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.

Na środowisku testowym generator QR sypał kod z adresem typu K: cała linia „Bundesgasse 1, 3005 Bern” 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 bernskie. 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. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja.

#Rynek Berna: administracja, usługi i handel detaliczny

Berno łączy administrację federalną, telekomunikacje i dojrzały ekosystem usług profesjonalnych. Sklep B2C w centrum miasta i sklep B2B dostarczający do instytucji federalnych mają inne wymagania checkoutu, ale ten sam stack płatności i podatku. W pierwszym przypadku decyduje TWINT Express i szybka etykieta PostPac. W drugim - faktura z góry, numer UID na PDF i ścieżka zatwierdzenia PO przed wysyłką.

Bern Digital Hub przyciąga startupy i software house’y, które często budują MVP sklepu na motywie i dopiero po pierwszym sezonie sprzedażowym odkrywają, że checkout nie obsługuje MWST per pozycja albo że webhook PostFinance nie dociera przez firewall hostingu poza CH. Naprawa idzie szybciej, gdy audyt na wejściu obejmuje listę wtyczek czytających zamówienia i test webhooka z zewnętrznego IP, nie tylko Lighthouse na stronie głównej.

Handel detaliczny w Starej Mieście i wokół Bahnhof Bern ma sezonowość turystyczną, ale stały ruch lokalny. Sklep, który pokazuje ceny tylko w EUR „dla turystów”, bez jawnej stopy przeliczenia i bez zgody na przetwarzanie, ryzykuje reklamację u EDÖB szybciej niż utratę konwersji. Checkout w CHF z opcjonalnym podglądem EUR w stopce to decyzja produktowa i prawna, nie CSS.

#Rozpocznij projekt sklepu WooCommerce w Bernie

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 (Ostermundigen, Wankdorf, 3PL) i czy Treuhänder 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. Berno 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.