Programista WooCommerce w Edynburgu

Sklep WooCommerce w Edynburgu konkuruje z kupującym, który płaci PayPalem albo Klarną w funtach brytyjskich, oczekuje dostawy Royal Mail albo DPD do mieszkania w Leith albo do punktu odbioru przy Princes Street i chce faktury VAT, którą księgowość wczyta do systemu zgodnego z Making Tax Digital. Checkout skopiowany z rynku europejskiego - euro jako waluta domyślna, brak Apple Pay, strefy dostaw opisane po polsku - 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 brytyjskich. Strona firmowa bez koszyka to osobna ścieżka: programista WordPress w Edynburgu. Sklep już na produkcji, który potrzebuje aktualizacji i kopii, a nie przebudowy checkoutu, idzie na opiekę techniczną WordPress w Edynburgu.

#Checkout WooCommerce w Edynburgu

Edynburg nie jest Glasgow nad Clyde ani Manchesterem z MediaCityUK. Stolica Szkocji ma inny profil klientów, inne tempo sezonów i inny ekosystem vendorów. Edynburg jest centrum fintechu (Fintech Scotland), turystyki festiwalowej, life sciences przy BioQuarter oraz spinoutów z Uniwersytetu Edynburgskiego i Heriot-Watt. CodeBase przy Castle Terrace to jeden z największych hubów technologicznych w Wielkiej Brytanii poza Londynem. To realny kontekst briefu: firma z Edynburga często obsługuje klientów całej Szkocji, w Anglii i za granicą, a sklep musi działać dla odbiorcy w Aberdeen albo Londynie bez osobnej instalacji na każde miasto.

Edinburgh Festival Fringe w sierpniu generuje skok ruchu, którego nie da się porównać ze stałą sprzedażą D2C. Sklep z merch festiwalowym, biletami, limitowanymi kolekcjami albo subskrypcją treści musi wytrzymać premierę o 19:00 w piątek, gdy tysiące osób wraca z spektaklu na Royal Mile i kupuje na telefonie w sieci LTE. Checkout, który nie przeżyje pierwszego weekendu Fringe, produkuje incydent operacyjny, nie „drobny ticket po weekendzie”.

Korytarz biznesowy wzdłuż Edinburgh Park i Gyle łączy biura korporacyjne, magazyny fulfilment i marki lifestyle sprzedające online równolegle z showroomem w West End. Leith nad Firth of Forth zbiera magazyny, producentów i marki D2C z wysyłką krajową. Oba rytmy - skok festiwalowy przy Fringe i stała sprzedaż z magazynu w Leith - kończą się w tym samym checkoucie WooCommerce w GBP.

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 w GBP na checkoucie w UK

Brytyjski koszyk w 2026 zaczyna się od metod, które kupujący rozpoznaje natychmiast. PayPal pozostaje portfelem, którego wielu klientów szuka w pierwszym ekranie metod. Klarna pokrywa Pay in 3, Pay in 30 days i raty na wyższy koszyk, szczególnie przy odzieży, merch festiwalowym i kosmetykach D2C z West End. Karta przez Stripe albo WooPayments zostaje jako warstwa uniwersalna z SCA i 3DS zgodnym z PSD2 w relacjach z bankami brytyjskimi. Apple Pay i Google Pay wchodzą jako warstwa karty na mobile, nie jako zamiennik PayPal.

Waluta sklepu to funt brytyjski (GBP). Wyświetlanie cen w euro albo dolarach na checkoucie skierowanym do klienta z Greater Edinburgh psuje zaufanie i generuje porzucenia koszyka, które wyglądają jak „błąd kursu”, a są błędem konfiguracji WooCommerce. Jeśli sklep obsługuje też klientów z Irlandii Północnej albo krajów UE, waluta i stawki podatkowe wymagają osobnej strefy, nie przełącznika CSS.

Kolejność metod na checkoucie ustawiamy pod ten mix: PayPal i Klarna wysoko, Apple Pay i Google Pay na mobile, karta niżej. Domyślny szablon Woo z kartą na górze pracuje wbrew nawykom rynku brytyjskiego. Dla subskrypcji WooCommerce Subscriptions Stripe albo PayPal muszą obsługiwać cykliczne obciążenia z zapisanym mandatem i webhookami renewal.

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. Stripe w praktyce zgłasza payment_intent.succeeded i charge.refunded osobnymi zdarzeniami. Klarna wymaga osobnej decyzji, czy capture idzie od razu, czy po nadaniu przesyłki - przy towarze fizycznym z magazynu w Leith druga opcja chroni przed pobraniem pieniędzy za SKU, którego nie ma.

#Strefy dostaw: Royal Mail, DPD i fulfilment

Krajowa dostawa w Wielkiej Brytanii w 2026 to przede wszystkim Royal Mail (Tracked 24, Tracked 48, Special Delivery) albo DPD Local / DPD Next Day. Evri nadal obsługuje tańsze przesyłki i punkty odbioru w supermarketach. Yodel i Parcelforce wchodzą tam, gdzie kontrakt magazynowy albo wolumen tego wymaga. W Edynburgu gęstość punktów odbioru w centrum, przy St James Quarter i w Leith jest wysoka: kupujący w mieszkaniu przy George Street często wybiera click-and-collect albo locker zamiast czekać na kuriera w godzinach pracy.

Strefy Woo rozdzielamy nie tylko na „UK mainland / Scottish Highlands & Islands / Northern Ireland / reszta świata”, ale na wagę i wymiar: do progu małej paczki Royal Mail, powyżej kurier DPD do drzwi albo paleta. Jedna stawka „darmowa dostawa UK” na wszystko psuje marżę na gabarycie i konwersję na drobnicy. Northern Ireland po Brexicie wymaga osobnej logiki podatkowej i celnej (Windsor Framework), nie tej samej strefy co Szkocja i Anglia.

Magazyny w Leith, w Edinburgh Park albo w fulfilmentcie 3PL obsługującym marki z CodeBase mają inny rytm niż sklep z biurem w New Town, który obiecuje odbiór osobisty w godzinach biurowych. 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 Royal Mail albo DPD policzy routing. Ręczne klejenie etykiet w portalu przy skoku po premierze Fringe nie skaluje się.

Integracja z wtyczkami etykiet (ShipStation, Shiptheory, oficjalne konektory DPD albo Royal Mail) wymaga mapowania usług na strefy Woo. Aktualizacja wtyczki etykiet, która na produkcji nadpisze mapowanie usług, zostawia magazyn z ręcznym klejeniem numerów. Dlatego te wtyczki nigdy nie idą w tym samym oknie co drobna aktualizacja SEO.

#VAT, Making Tax Digital i sprzedaż transgraniczna po Brexicie

Stawka VAT standardowa w Wielkiej Brytanii to 20 procent. Stawka obniżona 5 procent dotyczy wybranych kategorii. Stawka zero procent obejmuje m.in. większość żywności i książek. Koszyk mieszany jest codziennością przy sklepie, który sprzedaje merch festiwalowy obok książki albo zestaw kosmetyków obok akcesorium ze stawką zero. Woo musi liczyć podatek per pozycja, a nie „weź najwyższą stawkę koszyka”. Błąd w klasie podatkowej produktu wychodzi dopiero na fakturze VAT i w raporcie do HMRC.

Making Tax Digital (MTD) wymaga od firm powyżej progu VAT cyfrowego raportowania do HMRC przez oprogramowanie kompatybilne z API. WooCommerce sam z siebie nie jest modułem MTD. Albo wtyczka podatkowa albo integracja z Xero, QuickBooks albo Sage generuje raport VAT, albo ERP jest źródłem podatku, a Woo tylko zbiera adres i kwoty. Mieszanie obu źródeł to najczęstszy rozjazd w deklaracji kwartalnej.

Sprzedaż B2B z ważnym numerem VAT (GB VAT number) może iść jako reverse charge albo zero-rated tam, gdzie przepisy na to pozwalają, o ile numer przejdzie walidację i sklep zapisze dowód sprawdzenia przy zamówieniu. Pole VAT number na checkoucie, walidacja i przełączenie klasy podatkowej to nie ozdoba formularza.

Sprzedaż do krajów UE po Brexicie wymaga osobnej logiki: IOSS dla małych przesyłek, rejestracja VAT w kraju docelowym albo lokalny agent przy wyższych wolumenach. Sklep z Edynburga, który „na razie sprzedaje tylko w UK”, przekracza próg ciszej niż zakłada, bo turystyka festiwalowa i eksport z BioQuarter generują zamówienia z adresem dostawy za granicą.

Granicę „co liczy podatek i wystawia dokument” zapisujemy w runbooku: WooCommerce Tax, TaxJar, osobny silnik faktur albo system księgowy. Jedno źródło numeracji faktur VAT. Dwa źródła dają podwójne numery albo dziury, a audyt HMRC tego nie wybacza.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Edynburgu, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu „Place order” albo „Pay with PayPal”. Sklep z magazynem w Leith, 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 tramwaju między Waverley a Princes Street, 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 faktury VAT, nadanie Royal Mail albo DPD - zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i Stripe, PayPal 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. 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, 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.

#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 PayPal na ostatnią sztukę limitowanego merchu przed premierą spektaklu i oboje dostają 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 Amazon, eBay albo innym kanale. Źródłem prawdy zostaje wspólna pula w ERP albo w warstwie fulfilment, a Woo trzyma stan przez synchronizację. Mapowanie SKU, jednostek i klas podatkowych ustalamy na architekturze.

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

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 i psuje eksport do Xero. Oficjalne Stripe, PayPal Payments i Klarna są na HPOS od dawna. Problemem są stare konektory magazynowe i autorskie crony.

Log ma pozwolić odtworzyć historię zamówienia bez logowania do panelu PayPal albo Stripe. Do dziennika przez wc_get_logger trafia identyfikator zdarzenia, status przed i po, kwota i decyzja. Nie trafia pełny payload z danymi płatniczymi.

#UK GDPR, cookies i dane klientów sklepu

Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. ICO (Information Commissioner’s Office) nadzoruje przetwarzanie danych. Dla sklepu WooCommerce w Edynburgu to nie jest abstrakcyjny paragraf prawny. To decyzje w checkoutcie, w wtyczkach consent, w polityce prywatności i w przechowywaniu danych klientów.

Co wpisujemy w brief i w kod:

• Checkout zbiera tylko pola potrzebne do realizacji zamówienia i dostawy. Pola marketingowe są opcjonalne i oddzielone od płatności. Zgoda na newsletter nie może być domyślnie zaznaczona.
• Wtyczki consent (CookieYes, Complianz, podobne) konfigurujemy tak, żeby skrypty marketingowe (Meta Pixel, Google Ads, TikTok) nie ładowały się przed akceptacją. To decyzja w motywie i w kolejności enqueue, nie ticket opieki po pierwszym raporcie ICO.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa. W Edynburgu te strony są elementem compliance, nie stopką marketingową.
• Integracje z CRM (HubSpot, Salesforce, Klarna Customer Data) dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem. Umowy powierzenia przetwarzania (DPA) to decyzja klienta, ale konfiguracja WooCommerce musi umożliwiać realizację tej decyzji.
• Retencja danych zamówień i kont klientów jest uzgodniona z polityką firmy i wymogami podatkowymi (faktury VAT muszą być dostępne przez okres wymagany przepisami).

PCI DSS dotyczy przechowywania danych kart. WooCommerce z Stripe albo PayPal nie trzyma numerów kart w bazie WordPressa. Własne pola „numer karty” w checkoutcie to błąd architektury, nie feature. Tokenizacja idzie przez bramkę.

Sklepy obok ekosystemu fintech w Edynburgu nie są systemami core bankingu, ale wyciek danych kart z źle skonfigurowanej wtyczki płatności to incydent, który trafia do ICO i do procesora płatności. Fintech Scotland promuje standardy w regionie, ale odpowiedzialność za checkout Woo leży po stronie właściciela sklepu i jego dostawcy technicznego.

#Zwroty i Consumer Rights Act

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty Terms & Conditions, Returns Policy i Privacy Policy zatwierdza kancelaria albo odpowiedzialny w firmie. Zadaniem Woo jest spiąć ten tekst z koszykiem, z przyciskiem, z mailem i z magazynem.

Konsument w Wielkiej Brytanii ma 14 dni na odstąpienie od umowy zawartej na odległość (Consumer Contracts Regulations 2013). Termin zaczyna biec od otrzymania towaru. Dla magazynu w Leith to SKU, którego nie wolno sprzedać drugi raz, bo może wrócić za dwa tygodnie. Consumer Rights Act 2015 dodaje prawo do towaru „as described, of satisfactory quality and fit for purpose” przez rozsądny okres.

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

1. Klient składa wniosek o zwrot 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ą Royal Mail albo instrukcję nadania.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na Stripe, PayPal albo Klarna.
4. Częściowy zwrot (jedna pozycja z trzech) nie zamyka całego zamówienia; kwoty bierze się z pozycji, nie z ręcznego „zwróć wszystko”.
5. Towar wyłączony ze zwrotu (higiena, personalizacja, treść cyfrowa po rozpoczęciu pobierania) musi mieć tę informację przy SKU przed zakupem.

Sezon po Edinburgh Festival Fringe to test tej ścieżki. Sklep, który w wrześniu ręcznie klika zwroty w panelu PayPal, a stany poprawia w Excelu, rozjeżdża raport VAT i nadsprzedaje wracający towar.

#Katalog i checkout pod Fringe, Hogmanay i kalendarz premier

Edynburg ma własny rytm sprzedaży. Edinburgh Festival Fringe w sierpniu, Royal Edinburgh Military Tattoo, Hogmanay na Princes Street, jarmarki świąteczne i kampanie B2B wokół Edinburgh Tech Meetup generują skoki ruchu w godzinach, nie w tygodniach. Sklep, który w tych oknach wgrywa nową wtyczkę płatniczą 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 Fringe 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”.

Preorder przed dropem: SKU jest widoczny, płatność schodzi w GBP, ale fulfillment stoi aż do daty. Status on-hold albo własny status „awaiting stock” musi blokować etykietę Royal Mail. Hold stock na preorderze jest dłuższy niż na towarze z półki.

Subskrypcja nie jest wtyczką „włącz i zapomnij”. Cykl, mandat Stripe albo PayPal, skip shipment, zmiana SKU w trwającej umowie i zwrot pierwszej dostawy to osobne ścieżki. Woo Subscriptions musi pisać do tych samych tabel HPOS co zamówienie jednorazowe.

Ceny netto / brutto na checkoucie B2B (netto plus VAT) i B2C (brutto z VAT) to dwa szablony, nie przełącznik CSS. Kupujący z VAT number w Edinburgh Park oczekuje netto. Konsument z Stockbridge oczekuje brutto w GBP.

Język checkoutu: sklep w Edynburgu często idzie po angielsku jako kanon, z wariantami dla rynku walijskiego albo irlandzkiego tam, gdzie firma faktycznie dostarcza. WPML WooCommerce Multilingual albo TranslatePress nie mogą rozjechać klas podatkowych i metod dostaw między językami.

#Kalendarz freeze: kiedy checkoutu nie ruszamy

Daty Fringe, Hogmanay, Black Friday, Edinburgh International Science Festival i kampanii medialnych wpisujemy w runbook wydań. W oknie Fringe, szczytu Hogmanay i dużych kampanii B2B na produkcję nie wchodzi: nowa bramka płatnicza, przełączenie HPOS, zmiana stref Royal Mail albo DPD, aktualizacja wtyczki podatkowej, która dotyka numeracji faktur VAT. Łatka bezpieczeństwa, która nie może czekać, idzie przez środowisko testowe w godzinach, nie w nocy przed premierą o 19:00.

Sklep, który sprzedaje merch w czasie Fringe, dostaje drugi wektor ruchu poza stałą ofertę. 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.

#Edynburg: fintech, turystyka i BioQuarter

Edynburg nie jest Glasgow z whisky ani Aberdeen z offshore. Tu liczy się fintech (FreeAgent, startupy w CodeBase, partnerstwa Fintech Scotland), turystyka (bilety, merch, vouchery na Royal Mile), life sciences przy BioQuarter (B2B, reagenty, sprzęt laboratoryjny) oraz kreatywna gospodarka (druk, licencje, merch festiwalowy).

#Fintech i B2B w stolicy Szkocji

Sklep B2B dla firmy z ekosystemu fintech często potrzebuje cen według roli klienta, numeru VAT na fakturze, płatności odroczonej poza checkoutem i osobnego portalu zamówień. WooCommerce B2B musi współgrać z Xero albo Sage po stronie klienta, nie tylko z panelem Woo. Webhook do ERP przy statusie „processing” i idempotencja to minimum, nie slajd na pitch decku.

#Merch festiwalowy i sezonowość

Edinburgh Festival Fringe to największy festiwal sztuk performatywnych na świecie. Sklep merch uruchamia się na tydzień przed premierą, dostaje wielokrotny ruch w weekend, potem wraca do baseline. WooCommerce w takim profilu potrzebuje stagingu przed sezonem, freeze wdrożeń w oknie sprzedaży, cache warmup i monitoringu checkoutu w czasie rzeczywistym. Action Scheduler i kolejka maili muszą wytrzymać szczyt bez zatykania cronów hostingu shared.

War story z briefów: sklep z koszulkami i plakatami działał dobrze poza sezonem, ale w pierwszy weekend Fringe checkout padł na timeout webhooka Stripe, bo handler generował etykietę Royal Mail synchronicznie. Naprawa to Action Scheduler, idempotencja i test obciążeniowy przed sierpniem, nie nowy motyw.

#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 Stripe ł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. Dropy przed Fringe generują ciężkie JPEG ze studia; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk „Add to basket”. Query Monitor na stagingu pokazuje, czy wtyczka podatkowa, konektor DPD i bramka nie dokładają po N zapytań na każdy request koszyka.

Pomiar: Lighthouse i dane terenowe na URL produktu, kategorii i checkoutu, przed i po. Bez procentów z sufitu. Jeśli po zmianie INP na checkoucie nadal blokuje skrypt Klarna, problemem jest kolejność ładowania, nie ogólna „optymalizacja”.

Hosting w UK (Krystal, 20i, Cloudways z DC w Londynie albo Edynburgu) plus CDN z terminalem TLS w Wielkiej Brytanii zwykle wystarcza dla kupujących ze Szkocji. Pytanie „czy origin jest w UK” wraca częściej niż we Frankfurcie, bo tu latency ma znaczenie przy mobile checkout w godzinie premiery spektaklu.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe VAT, kolejność metod płatności w GBP, strefy Royal Mail i DPD, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, ścieżkę zwrotu Consumer Rights Act, eksport do Xero albo QuickBooks, baseline Lighthouse, kalendarz Fringe i Hogmanay. 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: Stripe test mode, PayPal sandbox, Klarna playground. QA kończy się zamówieniem, które przechodzi: koszyk mieszany ze stawkami VAT, webhook, notatka w zamówieniu, etykieta, mail, a potem zwrot częściowy na tę samą bramkę.

Przekazanie to runbook bramek, mapa stref, opis zwrotów po stronie sklepu, instrukcja eksportu VAT, zapis decyzji HPOS i kalendarz freeze premier. Wycena jest indywidualna i na piśmie przed startem. Nie publikujemy cennika SKU na tej stronie.

Filary oferty, gdy zakres wychodzi poza ten audyt: programista WordPress przy stronie bez koszyka, utrzymanie stron WordPress 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ść w GBP, dostawa, stan, faktura VAT, zwrot. Motyw bloga, Gutenberg, intranet albo strona korporacyjna z New Town bez koszyka nie są tutaj tematem - to programista WordPress w Edynburgu. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Edynburgu. Wspólny filar e-commerce: programista WooCommerce.

Edinburgh WordPress Meetup spotyka się regularnie w okolicach miasta i zbiera developerów, agencje i freelancerów pracujących na WordPressie w regionie. To nie jest kanał sprzedaży. To sygnał, że lokalna społeczność zna WordPress Coding Standards, debatuje o Gutenbergu i widzi różnicę między motywem blokowym a page builderem. Informatics Ventures i Data Lab tłumaczą, skąd biorą się sklepy z wysokim udziałem mobile checkout i zwrotów przy merch festiwalowym. Nie tłumaczą, czemu webhook Stripe bez idempotencji zostawia zamówienie w pending po udanej płatności.

#Rozpocznij projekt sklepu WooCommerce w Edynburgu

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone, czy waluta to GBP, skąd leci Royal Mail albo DPD (magazyn w Leith, 3PL, click-and-collect w centrum), czy HPOS jest włączony, czy księgowość czeka na eksport VAT, czy polityka zwrotów jest spięta z checkoutem, oraz czy w kalendarzu jest Fringe, Hogmanay albo kampania w St James Quarter. 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. Edynburg dostaje ten sam rygor inżynierski co każdy inny sklep brytyjski, tylko ze stackiem płatności w GBP, logistyki Royal Mail i DPD, kontekstem CodeBase i Fringe oraz kalendarzem premier, których kupujący w stolicy Szkocji naprawdę używa.