WooCommerce Utvikler i Glasgow

En WooCommerce-butikk som selger til kunder i Skottland må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Stripe i britiske pund med Strong Customer Authentication, UK MVA på 20 prosent regnet riktig, og frakt via Royal Mail eller DPD med sporingsnummer kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Glasgow med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Det skotske detaljhandelsmarkedet er konsentrert rundt Argyle Street og Buchanan Galleries, men netthandelen når langt utenfor sentrum. En uavhengig produsent i Merchant City som selger håndlagde varer til resten av Storbritannia trenger en kasse som tar GBP på alvor, håndterer ICO-kravene til personvern, og lar dem styre frakt selv uten å stole på en mal fra et annet marked.

#WooCommerce-utvikling i Glasgow

Glasgow-kunder er vant til raske kasser, tydelig totalpris med MVA inkludert, sporbar frakt og en enkel returprosess innenfor Consumer Rights Act. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en britisk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Stripe i GBP i kassen: kortbetaling med 3DS2 der PSD2 krever det, Apple Pay og Google Pay der det gir mening, gjentakende betaling for abonnement, og test av webhooks for payment_intent.succeeded, charge.refunded og delvis refusjon mot testmiljø
• PayPal og Klarna ved siden av Stripe, med riktig rekkefølge i kassen for britisk trafikk og testkort-matrise per gateway
• UK MVA-oppsett: 20 prosent standardsats, redusert sats på visse varer, nullsats der det gjelder, og priser vist inkludert MVA slik britiske forbrukere forventer
• Frakt med Royal Mail og DPD: fraktsoner for Skottland, England, Wales og Nord-Irland, prisregler basert på vekt og dimensjoner, og sporingsnummer koblet mot ordrebehandlingen
• Retur og angrerett bygget inn i flyten: returskjema, riktig informasjon i ordrebekreftelse og e-post, slik at 14-dagersfristen under Consumer Rights Act ikke blir en manuell jobb for kundeservice
• ICO/GDPR-samsvar i kassen: samtykke til markedsføring som ikke er forhåndsavkrysset, cookie-banner i tråd med PECR, personvernerklæring lenket fra checkout, og databehandleravtale dokumentert for Stripe og andre leverandører
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor britiske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Glasgow er det ikke produktkatalogen som er vanskelig, det er kassen. Stripe oppfører seg annerledes enn et enkelt skjema: Payment Intent-flyten, 3DS2-utfordringen på mobil og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før Stripe faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte 3DS-betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Frakt er den andre fellen. En britisk kunde forventer å se Royal Mail eller DPD som leveringsalternativ, med et sporingsnummer i forsendelsesvarselet, ikke bare «standard frakt». Når dette mangler, faller konverteringen på mobil. Vi setter opp fraktsonene og leveringsvalgene som hører til det britiske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Glasgow

Glasgow er det tyngste teknologimiljøet i Skottland utenfor Edinburgh. CodeClan, det skotske bootcamp-miljøet for utviklere, har base her, og WordPress Glasgow meetup møtes jevnlig for å dele erfaringer rundt WordPress og WooCommerce. Selskaper i turisme og kreativ industri, fra whisky- og tekstilmerker til uavhengige designere langs Argyle Street, selger i økende grad direkte til forbruker via egen nettbutikk.

Kundene våre i Glasgow spenner fra nisjebutikker som selger håndlagde varer til resten av Storbritannia, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar Stripe i GBP på alvor, regner UK MVA riktig, oppfyller ICO-kravene til personvern, og lar dem styre frakt selv.

Mange av disse butikkene har vokst organisk over flere år: et tema fra en kjøpt mal, et halvt dusin tillegg som overlapper, og en kasse som er lappet sammen i takt med at nye krav dukket opp. Det fungerer helt til trafikken øker, et betalingstillegg slutter å bli vedlikeholdt, eller MVA-reglene endrer seg. Da er det ikke en ny plugin som trengs, men en opprydding i arkitekturen: skille ut egen kode i en egen plugin, fjerne tillegg som dupliserer hverandre, og gjøre kassen forutsigbar igjen. Vi tar denne typen refaktorering uten å bygge alt på nytt, så lenge WooCommerce er riktig plattform for det butikken skal gjøre. Er det ikke det, sier vi det skriftlig.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Stripe, PayPal, Klarna), fraktsoner mot Royal Mail og DPD, UK MVA-regler, ICO/GDPR-spor i kassen og Lighthouse-måling på de mest besøkte produkt- og kategorisidene.
2. Plan for betaling, frakt og integrasjon. Vi dokumenterer gateway-valg og rekkefølge i kassen, fraktsoner og leveringslogikk, UK MVA-håndtering, og koblinger mot regnskap, lager eller fulfilment. Grensen mellom Woo-kjerne, egen plugin og temakode settes her.
3. Bygging i feature-brancher. Vi følger kodestandardene til WordPress og WooCommerce, utvider Woo via action- og filter-hooks i stedet for å endre kjernen, og tester betalings- og ordrestier underveis.
4. QA på ordrestien. Handlekurv, kasse, betaling med testkort på Stripe i GBP, refusjon og delvis refusjon, retur etter Consumer Rights Act, kunde-e-post og admin-redigering, kjørt i et testmiljø som speiler produksjon.
5. Utrulling og overlevering. Vi deployer via en dokumentert release-prosess med testet tilbakeføring, og leverer runbook for hver gateway og hver integrasjon sammen med dokumentasjon for butikkstyrere og redaktører.

#Typiske oppdrag fra Glasgow-butikker

• Stripe var feilkoblet. En uavhengig tekstilbutikk i Merchant City markerte ordrer betalt på redirect i stedet for på webhook. Vi flyttet bekreftelsen til payment_intent.succeeded-webhooken, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon i GBP.
• Treg kasse på mobil. En whisky-merkevarebutikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før Stripe-knappen var klikkbar. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kallene og autoloadede options som var skyld i mesteparten, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.
• UK MVA og cookies var feil. En kreativ industri-butikk som solgte både innen Skottland og til resten av Storbritannia viste priser uten MVA og hadde markedsføringssamtykke forhåndsavkrysset i kassen. Vi rettet MVA-visningen, fjernet forhåndsavkryssing i tråd med ICO-veiledningen, og koblet cookie-banneret til PECR-kravene.

#Tekniske standarder

Vi kjører WooCommerce på PHP 8.2 eller nyere, med object caching (Redis) der trafikken forsvarer det, og CDN foran statiske ressurser. Betaling går via Stripe i GBP, med PayPal og Klarna der butikken trenger det, alltid med 3DS2 på kort der PSD2 krever det. Tunge jobber, som synkronisering mot lager eller regnskap, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som tar Stripe i GBP på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det britiske kunder forventer fra Royal Mail og DPD, UK MVA og returrett håndtert i selve flyten i stedet for manuelt, ICO/GDPR-spor dokumentert i kassen og cookies, og en målbar forbedring i Core Web Vitals på de sidene som faktisk konverterer. Måltallene settes mot dagens nivå i revisjonen, ikke mot oppdiktede bransjegjennomsnitt.

#Sikkerhet og personvern

Hvert prosjekt får en sikkerhetsgrunnlinje: HTTPS med HSTS, Content Security Policy mot XSS, sårbarhetsskanning av avhengigheter i CI, tofaktor for administratorkontoer og testede sikkerhetskopier. Butikker som håndterer personopplysninger får UK GDPR-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen. ICO forventer at nettbutikker kan dokumentere lovlig grunnlag for behandling, samtykke der det kreves, og at kundedata fra Stripe-betalinger og fraktadresser lagres og slettes i tråd med retningslinjene. Vi setter opp cookie-kategorier i tråd med PECR, lenker personvernerklæring fra checkout, og dokumenterer databehandleravtaler med Stripe og fraktleverandører.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en nettbutikk er det kasse-, produkt- og kategorisidene som betyr noe. Vi jobber mot lav LCP gjennom optimalisert kritisk renderingsvei og forhåndsinnlasting av hero-bilder i moderne format (WebP/AVIF), lav INP gjennom minimal JavaScript og utsatt innlasting av tredjepartsskript (inkludert Stripe.js), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som betalingsknappen. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Glasgow-butikker stiller oss

Setter dere opp Stripe i GBP i kassen? Ja. Vi integrerer kortbetaling med 3DS2, Apple Pay og Google Pay der det passer, og tester autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø før lansering. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere UK MVA riktig? Ja. Vi setter 20 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert MVA slik britiske forbrukere forventer, og skiller flyten for varer med ulike MVA-satser der butikken selger blandede kategorier.

Hvilke fraktløsninger støtter dere? Royal Mail og DPD, med fraktsoner for Skottland og resten av Storbritannia, prisregler etter vekt og dimensjoner, og fraktsedler og sporing koblet mot ordrebehandlingen.

Hva med ICO og GDPR? Vi setter samtykke til markedsføring uten forhåndsavkryssing, cookie-banner i tråd med PECR, personvernerklæring lenket fra checkout, og dokumenterer databehandleravtaler med betalings- og fraktleverandører.

Endrer dere WooCommerce-kjernen? Nei. Tilpasninger går via dokumenterte action- og filter-hooks, med en klar deling mellom egen plugin og tema, slik at butikken overlever Woo-oppdateringer.

Jobber dere med butikker utenfor Glasgow? Ja. Vi har tyngdepunktet i Glasgow-miljøet, men leverer til netthandlere i hele Skottland og resten av Storbritannia.

#Integrasjoner en skotsk nettbutikk faktisk trenger

En skotsk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Stripe i GBP, frakt med Royal Mail eller DPD inkludert sporingsnummer, regnskap i Xero eller Sage, og en ordrestatus som settes av serveren til leverandøren, ikke av at kunden tilfeldigvis kommer tilbake til takkesiden. Rekkefølgen er ikke tilfeldig: hver kobling nedover i listen arver feilene fra den over hvis den første ikke er riktig bygget.

#Betaling: Stripe i GBP

Stripe er en Payment Intent-flyt, ikke et skjema. Integrasjonen bygges mot Payment Intents API for engangskjøp og mot Stripe Billing for gjentakende trekk. Butikken oppretter en betaling, sender kunden gjennom 3DS2 der det kreves, og venter. Alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect eller client-side bekreftelse og ingenting mer, mens fullføringen skjer i webhook-håndtereren. Ordren får payment_complete først når Stripe har bekreftet.

Reserver nå, trekk ved forsendelse. Britisk praksis for varesalg er å autorisere beløpet ved kjøp og belaste det når varen sendes. Det betyr at integrasjonen må skille tydelig mellom autorisasjon, belastning, delvis belastning, annullering og refusjon, og at hver av disse må kunne utløses både fra Woo-admin og fra en bakgrunnsjobb. Delvis belastning er en vanlig kilde til avvik når en ordre sendes i to forsendelser.

PayPal og Klarna går ved siden av, ikke i stedet for. De dekker kunder som foretrekker dem fremfor kort, alltid med egne webhook-formater. To eller tre gatewayer betyr flere sett med statuskoder, refusjonsmodeller og webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker. Uten dette blir refusjon fra admin et gjettespill.

HPOS må deklareres. På butikker med High-Performance Order Storage må egen plugin-kode melde kompatibilitet via FeaturesUtil::declare_compatibility på before_woocommerce_init, og all lesing og skriving av ordredata må gå gjennom wc_get_order og CRUD-metodene i stedet for direkte postmeta-kall. Gammel gateway-kode som skriver med update_post_meta slutter å virke uten å gi feilmelding.

#Frakt: Royal Mail og DPD

Fraktpriser hentes, de gjettes ikke. Royal Mail Shipping API og DPD Local gir pris og leveringstid per produkt og postnummer. Svaret kobles inn i kassen via woocommerce_package_rates, med volumvekt regnet ut fra pakkens dimensjoner der den overstiger faktisk vekt. Svarene mellomlagres i transienter per postnummer og vektklasse, fordi kassen ikke kan vente på et eksternt kall ved hver oppdatering av handlekurven.

Sporing hører hjemme i e-posten. Sporingsnummeret lagres på ordren og skrives inn i forsendelsesvarselet, typisk via woocommerce_email_before_order_table. Det fjerner en av de vanligste henvendelsene til kundeservice fra kunder som venter på levering til Highlands eller resten av Storbritannia.

Tidsavbrudd krever en reserveløsning. Når frakt-API-et ikke svarer, skal kassen falle tilbake til en definert standardsats i stedet for å vise en kasse uten fraktvalg. Feilen logges via wc_get_logger med egen kilde, slik at hyppige tidsavbrudd blir synlige i WooCommerce-loggen før kundeservice oppdager dem.

Nord-Irland krever egen oppmerksomhet. Etter Brexit gjelder egne MVA-regler for varer sendt til Nord-Irland. Fraktsoner og MVA-logikk må skille dette fra ordinær innenlands levering til England, Wales og Skottland.

#Regnskap: Xero eller Sage

Salget bokføres én gang, med riktig MVA-kode. Både Xero og Sage har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MVA-kode i stedet for å sende en flat sats. Nummeret på det opprettede dokumentet skrives tilbake på ordren, og eksistensen av dette nummeret er det som hindrer dobbeltbokføring ved en ny kjøring.

Avstemming er mot utbetaling, ikke mot ordre. Stripe utbetaler samlet og trekker gebyr. Regnskapet stemmer først når integrasjonen bokfører utbetalingen som en egen post med gebyret skilt ut, ikke når hver ordre er bokført hver for seg.

Making Tax Digital for MVA-registrerte. Selger butikken over terskelen for MVA-registrering, må digitale MVA-returer sendes via MTD-kompatible program. Xero og Sage støtter dette, men integrasjonen fra WooCommerce må overføre nok informasjon til at arkivet er komplett.

Synkronisering kjøres i kø. All overføring til regnskap legges på Action Scheduler med gjentatte forsøk ved feil, aldri synkront i kasseforespørselen. En regnskapstjeneste som er nede, skal forsinke bokføringen, ikke blokkere et kjøp.

#Hvorfor ordrestatus må settes server-til-server

Takkesiden er et løfte, ikke et bevis. Kunden kan miste dekning på Subway i Glasgow, lukke nettleseren, bytte til en annen app mens betalingen fullføres, eller ha telefonen i bakgrunnen når batteriet sparer strøm. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Betalingsbekreftelsen fra Stripes server er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser først, kvitter raskt, jobb etterpå. Webhook-endepunktet skal først verifisere signaturen på varselet mot webhook secret, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb. Stripe prøver på nytt når svaret drøyer, og et tregt endepunkt utløser dermed flere kopier av det samme varselet.

Idempotens lagres, den antas ikke. Hvert varsel har en Stripe event ID. Den lagres når hendelsen er behandlet, og et varsel med en allerede lagret ID forkastes. Uten dette gir gjentatte forsøk dobbel belastning, dobbel bokføring i regnskapet og dobbelt kunde-e-post. Hendelser kan også komme i feil rekkefølge, så håndtereren må tåle en belastningsmelding som kommer før autorisasjonsmeldingen.

Endepunktet må være åpent for maskiner. Webhook-URL-en skal holdes utenfor sidecache, ikke stå bak passordbeskyttelse eller IP-sperre, og ikke ligge på et testmiljø som krever innlogging. Dette er en vanlig årsak til at en integrasjon virker i testmiljø og ikke i produksjon.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter status fra Stripe for ordrer som har blitt stående som ventende lenger enn et definert vindu, og retter opp der webhooken aldri kom fram. Jobben kjøres via ekte systemcron mot wp cron event run --due-now med DISABLE_WP_CRON satt, fordi WordPress’ egen pseudo-cron avhenger av trafikk og dermed er upålitelig akkurat når butikken er stille om natten.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt 3DS, webhook som kommer to ganger, webhook som kommer i feil rekkefølge, forsinket webhook, frakt-API som svarer for sent, og regnskaps-API som avviser dokumentet. Hver av disse skal ende i en ordre med riktig status og en linje i loggen. Reaksjonstider ved feil i drift avtales skriftlig i vedlikeholdsavtalen.

#WooCommerce i andre britiske byer

Trenger du WooCommerce-hjelp utenfor Glasgow, gjelder de samme britiske kravene til Stripe i GBP, UK MVA og ICO/GDPR, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Edinburgh, WooCommerce-utvikler i London og WooCommerce-utvikler i Manchester for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Glasgow oppdateringer, sikkerhetskopier og overvåking.

#Start et WooCommerce-prosjekt i Glasgow

Trenger butikken din i Glasgow en kasse som tar Stripe i GBP på alvor, regner UK MVA riktig og oppfyller ICO-kravene til personvern, ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens oppsett, peker på den faktiske flaskehalsen og gir en ærlig vurdering av hva som bør gjøres først. Omfanget og kostnaden avtales individuelt etter gjennomgang, og du får oversikten skriftlig før arbeidet starter.

For butikker og nettsteder som trenger en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon for WordPress.