WooCommerce Utvikler i Stuttgart

En WooCommerce-butikk som selger til tyske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Stripe DE med PSD2 og 3D Secure, MwSt på 19 prosent regnet riktig, og cookie-samtykke som tåler BfDI-tilsyn under DSGVO og TTDSG. Vi bygger og rydder opp i WooCommerce for bedrifter i Stuttgart med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Stuttgart er hjemsted for Mercedes-Benz Group i Untertürkheim, Porsche i Zuffenhausen og Bosch i Gerlingen-Schillerhöhe, med et tett nettverk av Tier-1- og Tier-2-leverandører i Schwaben rundt dem. En nettbutikk som selger reservedeler, verktøy eller B2B-komponenter til dette miljøet møter forventninger som går langt utover standard WooCommerce-oppsett: Kauf auf Rechnung, SEPA-avtale, SAP-kompatibel artikkelnummerering, og en kasse som ikke bryter sammen når BfDI stiller spørsmål om databehandling.

#WooCommerce-utvikling i Stuttgart

Stuttgart-markedet er konservativt og kvalitetsbevisst. Tyske netthandlere er vant til raske kasser, PayPal og SEPA ved siden av kort, tydelig pris med MwSt inkludert, og levering via DHL eller DPD med sporingslenke i e-posten. B2B-kjøpere i automotive-sektoren forventer i tillegg nettopriser, kundespesifikke prislister og en kasse som snakker med ERP uten manuell etterarbeid.

Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en tysk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Stripe DE i kassen: kortbetaling med 3D Secure 2.0 og PSD2 Strong Customer Authentication, Apple Pay og Google Pay, SEPA Direct Debit med mandat-workflow, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Klarna og PayPal ved siden av Stripe DE, med Kauf auf Rechnung der butikken trenger det, og riktig rekkefølge i kassen for tysk trafikk og testkort-matrise per gateway
• MwSt-oppsett for tysk handel: 19 prosent standardsats, redusert sats på 7 prosent der den gjelder, og priser vist inkludert MwSt slik tyske forbrukere forventer under Preisangabenverordnung
• OSS-håndtering for butikker som selger til andre EU-land: riktig MwSt-sats per destinasjonsland, og logikk som skiller innenlandsk tysk salg fra grenseoverskridende EU-salg
• Frakt med DHL, DPD og Hermes: fraktsoner, prisregler basert på vekt og dimensjoner, Packstation som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• BfDI/DSGVO-samsvar bygget inn i flyten: cookie-samtykke som blokkerer sporingskript før aksept etter TTDSG, personvernerklæring tilpasset e-handel, databehandleravtaler dokumentert, og logging som støtter varsling til BfDI ved personvernbrudd
• B2B-funksjoner for automotive-leverandører: nettopriser, kundespesifikke prislister, tilbudsforespørselsarbeidsflyter, og dedikerte portaler med SSO mot bedriftskontoer
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor tyske betalings- og personvernvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Stuttgart er det ikke produktkatalogen som er vanskelig, det er kassen og personvernet. Stripe DE oppfører seg ikke som et enkelt skjema: 3DS-utfordringen, redirect-flyten for visse betalingsmetoder og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før Stripe faktisk har bekreftet. Vi har sett automotive-reservedelsbutikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger og reserverte varer som aldri ble betalt.

Cookie-samtykke er den andre fellen. BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) fører tilsyn med GDPR-implementeringen i Tyskland, og TTDSG krever samtykke før ikke-essensielle cookies settes. En Tier-1-leverandør-butikk som laster Meta Pixel og Google Analytics før brukeren har akseptert, risikerer både juridisk etterspill og omdømmetap i et miljø der compliance er en del av innkjøpskriteriene. Vi setter opp samtykkehåndtering som blokkerer tredjepartsskript til brukeren har valgt, og dokumenterer valget slik at kunden kan vise BfDI hva som skjer.

Frakt er den tredje. En tysk kunde forventer å velge Packstation hos DHL eller et hentested i kassen, ikke bare «standard frakt». Når dette mangler, faller konverteringen på mobil. For tunge automotive-varer trenger kassen i tillegg spedisjonslogikk med avisering, noe standard Woo-frakt ikke dekker uten tilpasning.

#Markedet og miljøet i Stuttgart

Stuttgart er engineering-hovedstaden i Baden-Württemberg. Rundt Mercedes-Benz, Porsche og Bosch har et tett Mittelstand av Tier-1- og Tier-2-leverandører, verktøyprodusenter og spesialiserte grossister vokst frem. STARTUP AUTOBAHN på ARENA2036-forskningcampus og Messe Stuttgart med messer som AMB og Vision trekker internasjonale kjøpere til regionen. For en netthandler betyr det at konkurransen om tyske og internasjonale B2B-kunder er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt.

Kundene våre i Stuttgart spenner fra reservedelsgrossister som selger til verksteder og Tier-1-innkjøpere, til schwäbiske familiebedrifter som flytter fra telefon- og feltvert over til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar Stripe DE og Kauf auf Rechnung på alvor, regner MwSt riktig, tåler BfDI-tilsyn, og lar dem koble mot SAP eller JTL-Wawi uten manuell ordreoverføring.

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 BfDI endrer veiledningen for cookie-praksis. 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 DE, Klarna, PayPal, SEPA), fraktsoner mot DHL/DPD, MwSt-regler, cookie-samtykke 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 Packstationslogikk, MwSt- og OSS-håndtering, BfDI/DSGVO-krav, 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å hver gateway, refusjon og delvis refusjon, kunde-e-post og admin-redigering, cookie-samtykke og sporingskript, 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 Stuttgart-butikker

• Stripe DE mangler eller er feilkoblet. En reservedelsbutikk 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 via Stripe DE.
• Treg kasse på mobil. En B2B-butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før PayPal-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.
• BfDI-varsel om cookie-praksis. En automotive-leverandør lastet Meta Pixel og Google Analytics før brukeren hadde akseptert cookies. Vi satte opp samtykkehåndtering som blokkerer tredjepartsskript til valg er gjort, dokumenterte endringen, og verifiserte at ingen sporingskript lastes uten samtykke.
• MwSt og OSS regnet feil. En butikk som solgte både innenlands i Tyskland og til andre EU-land blandet sammen tysk MwSt og OSS-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og destinasjonsland, og fikk grenseoverskridende salg merket riktig.
• SAP-synkronisering passet ikke. Materialnumre i shoppen matchet ikke SAP-artikkelnumre, og prislister ble oppdatert manuelt. Vi bygde middleware som synkroniserer stamdata, lager og priser, og skrev tilbake ordrenummer til Woo etter vellykket SAP-bokføring.

#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 DE, Klarna og PayPal avhengig av hva butikken trenger, alltid med 3D Secure på kort. Hosting hos Hetzner, IONOS eller mittwald i Tyskland holder data innenfor DSGVO-rammen og gir kort latency mot det tyske publikum. Tunge jobber, som synkronisering mot SAP eller DATEV, 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 DE og Kauf auf Rechnung på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det tyske kunder forventer fra DHL og DPD, MwSt og cookie-samtykke 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 DSGVO-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen.

Det som gjør det forretningskritisk i Tyskland, er at et nettsted som behandler kundedata er underlagt DSGVO, med BfDI som føderalt tilsynsorgan og LfDI Baden-Württemberg som landets tilsynsmyndighet for virksomheter i Stuttgart-regionen. Ved et personvernbrudd gjelder artikkel 33 i DSGVO: varsling til tilsynsmyndigheten uten ugrunnet opphold, med 72 timer som ytre frist når bruddet medfører risiko for registrertes rettigheter. BfDI har utstedt veiledning og sanksjoner mot tyske virksomheter for utilstrekkelig sikkerhet, for sent varslet brudd og for cookie-praksis som ikke oppfyller TTDSG-kravene. Vi kan ikke erstatte kundens juridiske rådgiver, men leverer logger, tidslinje og endringslogg slik at kunden kan vurdere om BfDI må varsles.

Siden 28. juni 2025 gjelder Barrierefreiheitsstärkungsgesetz (BFSG) for forbrukerorienterte nettbutikker over Kleinstunternehmer-terskelen. Vi sjekker tastaturbetjening, kontrast, skjemaetiketter og feilmeldinger langs hele bestillingsstien, og dokumenterer standpunktet i en tilgjengelighetserklæring.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en B2B-reservedelsbutikk 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), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som Stripe-knappen. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Stuttgart-butikker stiller oss

Setter dere opp Stripe DE i kassen? Ja. Vi integrerer kort med 3D Secure, SEPA Direct Debit, Apple Pay og Google Pay, 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 MwSt og OSS riktig? Ja. Vi setter 19 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert MwSt slik tyske forbrukere forventer, og skiller OSS-flyten for grenseoverskridende EU-salg fra ordinært innenlandsk tysk salg.

Hva med BfDI og cookie-samtykke? Vi setter opp samtykkehåndtering som blokkerer sporingskript før brukeren har akseptert, dokumenterer valget, og verifiserer at Meta Pixel, Google Analytics og lignende ikke lastes uten samtykke. Dette er et teknisk krav med juridisk etterspill under TTDSG og DSGVO.

Hvilke fraktløsninger støtter dere? DHL, DPD og Hermes, med fraktsoner, prisregler etter vekt og dimensjoner, Packstation som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen. For tunge varer kobler vi spedisjon via Schenker eller Dachser.

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

#Integrasjoner en tysk automotive-nettbutikk faktisk trenger

En tysk automotive-nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Stripe DE, Klarna og PayPal, frakt med DHL eller DPD inkludert Packstation, regnskap i DATEV, 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 DE, Klarna og PayPal

Stripe DE er en gateway-klasse, ikke et skjema. Integrasjonen bygges mot Stripe Payment Intents API for engangskjøp og mot Stripe Billing for gjentakende trekk. Butikken oppretter en betaling, sender kunden gjennom 3DS der det kreves, og venter. Fullføringen skjer i webhook-håndtereren. Ordren får payment_complete først når Stripe DE har bekreftet. For tyske B2B-kunder legger vi SEPA Direct Debit med mandat-workflow parallelt med kort.

Klarna dekker Sofort, faktura og delbetaling. Klarna er et alternativ mange tyske butikker bruker parallelt med Stripe DE, spesielt for B2C med Kauf auf Rechnung og delbetaling. 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. Uten dette blir refusjon fra admin et gjettespill.

PayPal går ved siden av, ikke i stedet for. PayPal dekker kunder som foretrekker PayPal-konto fremfor kort, og PayPal Pay Later for delbetaling. For automotive B2B er PayPal sjeldnere enn SEPA og Kauf auf Rechnung, men i B2C-reservedelssegmentet er det fortsatt en forventet betalingsmetode.

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: DHL, DPD og Hermes med Packstation

Fraktpriser hentes, de gjettes ikke. DHL og DPD 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.

Packstation er et eget datafelt. Kunden velger et konkret utleveringssted eller en pakkeboks i kassen, og valget må lagres på ordren som en identifikator fra leverandøren, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren. Skrives den som en adresse i et notatfelt, må lageret slå den opp manuelt, og fordelen ved integrasjonen forsvinner.

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.

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, spesielt i B2B-segmentet der innkjøperen bestiller mange linjer og trenger sporingsinfo uten å logge inn.

#Regnskap: DATEV og SAP

Salget bokføres én gang, med riktig MwSt-kode. DATEV-Connect og unternehmen online har API-er for salgsdokumenter. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MwSt-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.

SAP for automotive B2B. Tier-1-leverandører krever at artikkelnummer i shoppen matcher SAP-materialnummer, at prislister synkroniseres fra SAP, og at salgsordre bokføres tilbake som SAP Sales Order. Vi bygger middleware mot OData-API-et i S/4HANA eller bruker eksisterende konnektorer, med kø og retry slik at en nede SAP-instans ikke blokkerer kjøp.

Avstemming er mot utbetaling, ikke mot ordre. Stripe DE 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.

Synkronisering kjøres i kø. All overføring til regnskap og ERP legges på Action Scheduler med gjentatte forsøk ved feil, aldri synkront i kasseforespørselen. En DATEV- eller SAP-tjeneste 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å S-Bahn i Stuttgart, 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 Stripe DE, Klarna eller PayPal 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 delt hemmelighet, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb. Leverandører 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 identifikator. Den lagres når hendelsen er behandlet, og et varsel med en allerede lagret identifikator forkastes. Uten dette gir gjentatte forsøk dobbel belastning, dobbel bokføring i DATEV 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 DE 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, 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 betaling, varsel som kommer to ganger, varsel som kommer i feil rekkefølge, forsinket varsel, frakt-API som svarer for sent, og DATEV-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 tyske byer

Trenger du WooCommerce-hjelp utenfor Stuttgart, gjelder de samme tyske kravene til Stripe DE, MwSt og BfDI, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i München, WooCommerce-utvikler i Hamburg og WooCommerce-utvikler i Köln for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Stuttgart oppdateringer, sikkerhetskopier og overvåking. Nordiske huber sammenligner ofte med vedlikehold i Berlin og vedlikehold i Frankfurt.

#Andre tyske og nordiske byer

Samme WooCommerce-leveranse finnes i flere byer, med lokalt tilpasset betaling og MVA:

• Berlin - WooCommerce-utvikler i Berlin
• Frankfurt - WooCommerce-utvikler i Frankfurt
• München - WooCommerce-utvikler i München
• Stockholm - WooCommerce-utvikler i Stockholm

#Start et WooCommerce-prosjekt i Stuttgart

Trenger butikken din i Stuttgart en kasse som tar Stripe DE og Kauf auf Rechnung på alvor, regner MwSt riktig og tåler BfDI-tilsyn, 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. Prisen settes individuelt etter omfang, 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.