WooCommerce Utvikler i Praha

En WooCommerce-butikk som selger til tsjekkiske kunder i Praha må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: GoPay eller Comgate i kassen, DPH regnet riktig, og frakt via Zásilkovna eller PPL med hentested kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i hovedstaden med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

GoPay og Comgate dekker det meste av tsjekkisk netthandel. En kasse uten minst én av dem taper konverteringer på mobiltrafikk fra Praha-kunder, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Praha

Praha-markedet er kresent. Tsjekkiske netthandlere er vant til raske kasser, bankoverføring og kortbetaling via lokale gatewayer, tydelig pris med DPH inkludert, og mulighet til å hente pakken på et Zásilkovna-utleveringssted. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en tsjekkisk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• GoPay i kassen: engangsbetaling, gjentakende trekk for abonnement, bankoverføring og kort via samme gateway, med test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Comgate ved siden av GoPay der butikken trenger det, med riktig rekkefølge i kassen for tsjekkisk trafikk og testkort-matrise per gateway
• DPH-oppsett for tsjekkisk handel: standardsats, redusert sats på matvarer og bøker, fritak der det gjelder, og priser vist inkludert DPH slik tsjekkiske forbrukere forventer
• CZK som primærvaluta med EUR som sekundær der turisme eller eksport krever det, uten at valutalogikken bryter DPH-beregningen i kassen
• OSS-flyt for butikker som selger til andre EU-land: riktig MVA-sats per destinasjonsland og dokumentasjon av terskelverdier
• Frakt med Zásilkovna og PPL: fraktsoner, prisregler basert på vekt og volum, hentested som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen
• Angrerett bygget inn i flyten: retur- og angreskjema, riktig informasjon i ordrebekreftelse og e-post, slik at den EU-lovpålagte angrefristen ikke blir en manuell jobb for kundeservice
• Flerspråklig storefront (CZ/EN/DE) der turisme eller eksport krever det, med hreflang, oversatte metadata og QA-regler som holder implementeringen innenfor avtalt omfang
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor tsjekkiske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Praha er det ikke produktkatalogen som er vanskelig, det er kassen. GoPay oppfører seg ikke som et generisk kortgateway: redirect-flyten, webhook-bekreftelsen og støtten for bankoverføring krever at ordrestatus ikke settes til betalt før GoPay faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Frakt er den andre fellen. En tsjekkisk kunde forventer å velge et Zásilkovna-utleveringssted i kassen, ikke bare standard frakt. Når dette mangler, faller konverteringen på mobil. Vi setter opp fraktsonene og leveringsvalgene som hører til det tsjekkiske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Praha

Praha er Tsjekkias tyngste e-handelsmarked. Alza.cz og Rohlík.cz har satt forventningene til kassefart og leveringstid for hele landet, og en WooCommerce-butikk i Praha konkurrerer mot den standarden hver dag. Tech-miljøet rundt Karlín og Holešovice huser produkt-SaaS-selskaper som Productboard, fintech-aktører og eksportbedrifter som selger fra Tsjekkia ut i EU. CzechInvest og inkubatorer som Startup Yard gir gründere tilgang til mentorer og kapital, men de forventer at nettbutikken de lanserer tar GoPay på alvor fra dag én.

Kundene våre i Praha spenner fra turisme- og hotellrelatert handel som trenger CZ/EN og EUR-visning, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som regner DPH riktig, lar dem styre frakten selv, og holder seg innenfor GDPR slik ÚOOÚ håndhever det.

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 DPH-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 (GoPay, Comgate, Stripe), fraktsoner mot Zásilkovna og PPL, DPH-regler 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 hentestedslogikk, DPH- og OSS-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 og test-transaksjoner på hver gateway, refusjon og delvis refusjon, retur etter angrerett, 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 Praha-butikker

• GoPay mangler eller er feilkoblet. En butikk markerte ordrer betalt på redirect i stedet for på webhook. Vi flyttet bekreftelsen til webhooken, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon.
• EUR-visning brøt CZK-kassen. En turismebutikk viste EUR for engelskspråklige besøkende, men GoPay ble kalt med CZK-beløp fra en gammel valutalogikk. Vi skilte visningsvaluta fra betalingsvaluta, sørget for at GoPay alltid mottok riktig beløp og valuta, og testet begge språkveiene mot testmiljø.
• Treg kasse på mobil. En butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før betalingsknappen 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.
• DPH og OSS regnet feil. En butikk som solgte både innenlands og til andre EU-land blandet sammen vanlig tsjekkisk DPH og OSS-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og fikk grenseoverskridende salg dokumentert riktig mot regnskapet.

#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 GoPay, Comgate og kort (Stripe) avhengig av hva butikken trenger, alltid med 3D Secure på kort. 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 GoPay på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det tsjekkiske kunder forventer fra Zásilkovna og PPL, DPH og angrerett håndtert i selve flyten i stedet for manuelt, 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 GDPR-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen.

I Tsjekkia håndheves GDPR av ÚOOÚ (Úřad pro ochranu osobních údajů). Det betyr i praksis at samtykke til markedsføring må være aktivt og dokumenterbart, at kunder har rett til innsyn og sletting, og at databehandleravtaler med GoPay, Comgate, Zásilkovna og andre leverandører må være på plass før lansering. Vi bygger samtykkebanner, cookie-kategorier og personvernerklæring inn i arkitekturen, ikke som et etterpåklipp. Ved personopplysningsbrudd kan meldeplikt til ÚOOÚ utløses innen 72 timer etter oppdagelse, så hendelseslogging og rutiner for innsyn og sletting dokumenteres i runbooken. For nettbutikker i Praha betyr det også at kundedata fra betalinger og fraktadresser behandles og lagres slik både GDPR og tsjekkisk praksis krever.

#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 betalingsskript fra GoPay og Comgate), 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 Praha-butikker stiller oss

Setter dere opp GoPay i kassen? Ja. Vi integrerer engangsbetaling, bankoverføring og gjentakende trekk 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 Comgate ved siden av GoPay? Ja. Vi setter begge gatewayer opp med riktig rekkefølge i kassen, dokumenterer testkort-matrise per gateway, og sørger for at ordren lagrer hvilken gateway som eide betalingen, slik at refusjon fra admin ikke blir et gjettespill.

Hvilke fraktløsninger støtter dere? Zásilkovna og PPL, med fraktsoner, prisregler etter vekt og volum, hentested som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Hvordan håndterer dere GDPR og ÚOOÚ-krav? Vi bygger samtykkehåndtering, cookie-kategorier og personvernerklæring inn i arkitekturen, sørger for databehandleravtaler med betalings- og fraktleverandører, og dokumenterer hvordan kundedata lagres, slettes og meldes ved brudd slik ÚOOÚ krever det.

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 Praha? Ja. Vi har tyngdepunktet i Praha-miljøet, men leverer til netthandlere i hele Tsjekkia og til tsjekkiske butikker drevet fra utlandet.

#Integrasjoner en tsjekkisk nettbutikk faktisk trenger

En tsjekkisk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med GoPay og Comgate, frakt med Zásilkovna eller PPL inkludert hentesteder, regnskap i et lokalt system som Money S3, Pohoda eller FlexiBee, 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: GoPay og Comgate

GoPay er en redirect-gateway, ikke et skjema. Integrasjonen bygges mot GoPay REST API for engangskjøp og gjentakende trekk. Butikken oppretter en betaling, sender kunden til GoPay 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 og ingenting mer, mens fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når GoPay har bekreftet.

Comgate går ved siden av, ikke i stedet for. Comgate dekker kunder som foretrekker den gatewayen, alltid med 3D Secure på kort. To gatewayer betyr to sett med statuskoder, to refusjonsmodeller og to webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker.

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.

#Frakt: Zásilkovna og PPL med hentesteder

Fraktpriser hentes, de gjettes ikke. Zásilkovna API 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.

Hentested er et eget datafelt. Kunden velger et konkret utleveringssted i kassen, og valget må lagres på ordren som en identifikator fra leverandøren, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren.

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.

Sporing hører hjemme i e-posten. Sporingsnummeret lagres på ordren og skrives inn i forsendelsesvarselet, typisk via woocommerce_email_before_order_table.

#Regnskap: Money S3, Pohoda eller FlexiBee

Salget bokføres én gang, med riktig DPH-kode. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig DPH-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. Betalingsleverandøren utbetaler samlet og trekker gebyr. Regnskapet stemmer først når integrasjonen bokfører utbetalingen som en egen post med gebyret skilt ut.

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.

#Hvorfor ordrestatus må settes server-til-server

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

Verifiser først, kvitter raskt, jobb etterpå. Callback-endepunktet skal først verifisere signaturen på varselet mot delt hemmelighet, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb.

Idempotens lagres, den antas ikke. Hvert varsel har en identifikator. Den lagres når hendelsen er behandlet, og et varsel med en allerede lagret identifikator forkastes.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter status fra leverandøren for ordrer som har blitt stående som ventende lenger enn et definert vindu, og retter opp der varselet aldri kom fram. Jobben kjøres via ekte systemcron mot wp cron event run --due-now med DISABLE_WP_CRON satt.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt betaling, varsel som kommer to ganger, varsel som kommer i feil rekkefølge, forsinket varsel, frakt-API som svarer for sent, og regnskaps-API som avviser dokumentet.

#WooCommerce i andre tsjekkiske byer

Trenger du WooCommerce-hjelp utenfor Praha, gjelder de samme tsjekkiske kravene til GoPay, DPH og frakt, men med lokal logistikk og kundemønster. Se WooCommerce-utvikler i Brno for hvordan oppsettet tilpasses landets andre teknologihub.

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

#Start et WooCommerce-prosjekt i Praha

Trenger butikken din i Praha en kasse som tar GoPay på alvor, regner DPH riktig og lar deg styre frakten selv, 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 avtales individuelt etter kartlegging, og du får oversikten skriftlig før arbeidet starter.