WooCommerce utvikler i Düsseldorf

En WooCommerce-butikk som selger til tyske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Stripe og PayPal med tysk betalingslogikk i kassen, MwSt. og USt-IdNr. for B2B-handel, og GDPR-krav som BfDI og Landesbeauftragte i Nordrhein-Westfalen faktisk håndhever. Jeg bygger og rydder opp i WooCommerce for bedrifter i Düsseldorf med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

NRW Mittelstand forventer dokumentasjon, ikke bare at nettbutikken ser bra ut. En GmbH med hovedkontor i Medienhafen spør ofte om hvor kundedata lagres, hvem som er databehandler, og om Stripe webhook-endepunkter ligger i EU. Det er det praktiske utgangspunktet for arbeidet vårt.

#Hva dekker WooCommerce-utvikling i Düsseldorf?

Düsseldorf er hovedstad i Nordrhein-Westfalen og et av de tetteste knutepunktene for Mittelstand i Tyskland: familieeide industribedrifter, logistikkselskaper, maskinprodusenter og B2B-leverandører som selger til hele Europa. Medienhafen ved Rhinen samler kontorer og europeiske datterselskaper, mens Königsallee og omegn holder reklame- og motebransjen. Messe Düsseldorf med boot, drupa og Interpack legger til trafikkspitser som en nettbutikk må tåle uten at kassen bryter sammen.

Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en tysk B2B- eller B2C-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: Payment Element med 3D Secure 2, Apple Pay og Google Pay der det passer, webhook-bekreftelse på serveren i stedet for redirect, og testmatrise for autorisasjon, belastning, refusjon og delvis refusjon mot Stripe testmodus
• PayPal og PayPal Pay Later ved siden av Stripe, med riktig rekkefølge i kassen for tysk trafikk og IPN/webhook-håndtering som ikke dobbelbokfører ordrer
• SEPA Lastschrift og SEPA-Überweisung for B2B-handelspartnere, med felt for IBAN, mandat og avstemming mot utbetaling fra betalingsleverandøren
• MwSt.-oppsett for tysk handel: 19 prosent standardsats, 7 prosent redusert sats der den gjelder, netto-priser for B2B med USt-IdNr.-validering via VIES, og korrekt OSS-logikk for EU-salg utenfor Tyskland
• Kauf auf Rechnung der det er forretningsmessig riktig, med kredittvurdering og ordrestatus som skiller reservert fra fakturert
• Frakt med DHL, DPD og Hermes: fraktsoner, vekt- og sperrgutregler, Packstation-adresser, og fraktsedler/sporing koblet mot ordrebehandlingen
• B2B-funksjoner for NRW Mittelstand: kundespesifikke netto-priser, staffelpriser, minimumsbestillingsmengder, tilbudsforespørsel og kostnadsstedsfelt
• Anbindelse til DATEV, JTL-Wawi, plentymarkets eller SAP-backbone med produktsync, multi-lager og konfliktløsning ved parallelle lager i Düsseldorf og omegn
• Flerspråklige butikker (tysk og engelsk som minimum) via WPML med lokalisert checkout og riktig MwSt. per locale
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor tyske betalings- og B2B-valg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Düsseldorf er det ikke produktkatalogen som er vanskelig, det er kassen. Stripe oppfører seg ikke som et enkelt skjema: Payment Element laster asynkront, 3DS kan utløses midt i flyten, og webhook-bekreftelsen kommer uavhengig av om kunden kommer tilbake til takkesiden. Jeg har sett butikker der ordrer ble markert betalt på redirect tilbake fra Stripe, ikke på payment_intent.succeeded, slik at avbrutte betalinger ga ordrer uten penger. Slike feil fanges bare med ende-til-ende-testing av selve betalingsflyten.

B2B er den andre fellen. En innkjøpsansvarlig i et datterselskap av et NRW-konsern vil utløse en bestilling som går rett inn i DATEV eller SAP uten manuell etterarbeid. USt-IdNr. må valideres, netto-priser vises riktig, og SEPA-mandatet må lagres på ordren som en identifikator, ikke som fritekst i et notatfelt. Når dette mangler, faller konverteringen blant handelspartnere som forventer en profesjonell B2B-portal, ikke en B2C-kasse med et ekstra felt.

#Hvordan ser markedet ut i Düsseldorf?

De som driver nettbutikk i Düsseldorf sliter sjelden med rekkevidde, nesten alltid med tillit og etterlevelse. Kjøpere i Nordrhein-Westfalen bryter av hvis betalingsdelen virker ufullstendig: ingen synlig Trusted-Shops- eller eKomi-segel, en Widerrufsbelehrung gjemt i footeren, et cookie-banner som setter for mange avkryssingsbokser på forhånd. En butikk som ikke mapper denne basen rent, taper omsetning før markedsføringen i det hele tatt biter.

Kundene våre i Düsseldorf spenner fra D2C-merkevarer nær Königsallee til B2B-leverandører i Heerdt eller Reisholz som selger reservedeler og industrikomponenter til hele Europa. Fellesnevneren er at de trenger en butikk som tar Stripe DE på alvor, regner MwSt. riktig, og lar dem styre integrasjonen mot regnskap og lager 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 rundt Messe Düsseldorf, et betalingstillegg slutter å bli vedlikeholdt, eller BfDI stiller spørsmål om databehandling. Da hjelper det å rydde i arkitekturen i stedet for å legge til enda en plugin: flytte egen kode til en egen plugin, fjerne tillegg som gjør det samme, og gjøre kassen forutsigbar igjen.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Stripe, PayPal, SEPA), fraktsoner mot DHL/DPD, MwSt.-regler og Lighthouse-måling på de mest besøkte produkt- og kategorisidene.
2. Plan for betaling, frakt og integrasjon. Jeg dokumenterer gateway-valg og rekkefølge i kassen, fraktsoner og Packstation-logikk, MwSt.- og B2B-håndtering, og koblinger mot DATEV, JTL-Wawi eller SAP. Her settes grensen mellom WooCommerce-kjernen, egen plugin og temakoden.
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 Stripe testmodus og PayPal sandbox på hver gateway, refusjon og delvis refusjon, B2B med USt-IdNr., kunde-e-post og admin-redigering, kjørt i et testmiljø som speiler produksjon. Ved messe-relevante butikker legger vi til lasttest som etterligner trafikken rundt boot eller drupa.
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.

#Hvilke oppdrag kommer typisk fra butikker i Düsseldorf?

• Stripe webhook manglet eller var feilkoblet. En B2B-leverandør i NRW markerte ordrer betalt på redirect i stedet for på payment_intent.succeeded. Vi flyttet bekreftelsen til webhook-håndtereren, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon mot Stripe testmodus.
• Treg kasse på mobil. En Mittelstand-butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før Stripe Payment Element var klar. Jeg startet med Lighthouse, WP-CLI-profilering og Query Monitor på kassesiden, fant cart fragments-kallene og autoloadede options som sto for det meste, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.
• MwSt. og USt-IdNr. regnet feil på engelsk checkout. En butikk med tysk og engelsk via WPML viste riktig netto-pris på DE, men feil MwSt.-sats på EN etter at USt-IdNr. ble validert for B2B-kunde. Vi skilte locale-spesifikk prislogikk, satte riktig sats per produktgruppe og testet begge språk i kasseflyten før produksjon.

#Tekniske standarder

Jeg kjører WooCommerce på PHP 8.2 eller nyere, med object caching (Redis) der trafikken forsvarer det, og CDN foran statiske filer. Hosting skjer som regel på tysk infrastruktur (Hetzner i Falkenstein eller Nürnberg, IONOS eller mittwald) for lav latens i Rheinland og forutsigbar databehandling under GDPR. Betaling går via Stripe DE, PayPal og SEPA avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot JTL-Wawi eller DATEV, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen.

#Hva du kan forvente etter lansering

Jeg lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det jeg leverer er en kasse som tar Stripe DE på alvor og bekrefter ordrer på webhook, ikke på redirect, B2B-flyt med USt-IdNr. og netto-priser der det hører hjemme, fraktvalg som matcher det tyske markedet forventer fra DHL og DPD, MwSt. og Widerrufsbelehrung 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ålene settes ut fra dagens nivå i revisjonen, ikke ut fra oppdiktede bransjesnitt.

#Sikkerhet og personvern

Hvert prosjekt får et grunnleggende sikkerhetsnivå: HTTPS med HSTS, Content Security Policy mot XSS, skanning av avhengigheter for sårbarheter i CI, tofaktor for administratorkontoer og testede sikkerhetskopier. Butikker som behandler personopplysninger, får samtykkehåndtering etter GDPR, databehandleravtale og personvern bygget inn i arkitekturen.

I Tyskland supplerer BDSG (Bundesdatenschutzgesetz) GDPR, håndhevet av BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) på føderalt nivå og Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen regionalt. Ved et personvernbrudd gjelder artikkel 33 i GDPR: varsling til tilsynsmyndigheten uten ugrunnet opphold, med 72 timer som ytre frist når bruddet medfører risiko for registrertes rettigheter. En oppdatering som aktiverer Meta Pixel før cookie-samtykke, eller en backup som lagrer persondata utenfor EU uten avtalt grunnlag, er tekniske feil med juridisk etterspill. Jeg dokumenterer hvor produksjon kjører, om CDN avslutter TLS i avtalt sone, og om Stripe webhook-endepunkter og backup-buckets ikke replikerer til USA uten Standard Contractual Clauses.

Cookie-banner og samtykke før markedsførings-tags er en del av arkitekturen, ikke et engangsprosjekt. Tysk praksis vektlegger aktivt samtykke og tydelig informasjon i Datenschutzerklärung, i tråd med TTDSG-kravene som OLG Düsseldorf har tolket strengt.

#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. Jeg 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 Payment Element), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som betalingsfeltet. Jeg måler fortløpende med Lighthouse i utrullingen, slik at en forverring stopper utrullingen før den når produksjon.

#Hvilke spørsmål stiller butikker i Düsseldorf oss?

Setter dere opp Stripe DE i kassen? Ja. Vi integrerer Payment Element med 3D Secure 2, Apple Pay og Google Pay der det passer, og tester autorisasjon, belastning, refusjon og delvis refusjon mot Stripe testmodus før lansering. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere MwSt. og USt-IdNr. for B2B? Ja. Vi setter 19 prosent standardsats og 7 prosent redusert sats der de gjelder, validerer USt-IdNr. via VIES, viser netto-priser for B2B-kunder og skiller OSS-flyten for EU-salg utenfor Tyskland fra ordinær innenlandsk MwSt.

Hvilke fraktløsninger støtter dere? DHL, DPD og Hermes, med fraktsoner, prisregler etter vekt og sperrgut, Packstation-adresser som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Endrer dere WooCommerce-kjernen? Nei. Tilpasninger går via dokumenterte action- og filter-hooks, med et klart skille mellom egen plugin og tema, slik at butikken tåler WooCommerce-oppdateringer.

Jobber dere med butikker utenfor Düsseldorf? Ja. Jeg har tyngdepunktet i NRW og det tyske markedet, men leverer til netthandlere i hele Tyskland og til eksportører som selger fra Düsseldorf til Nederland, Belgia og videre.

#Integrasjoner en tysk nettbutikk faktisk trenger

En tysk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Stripe DE og PayPal, frakt med DHL eller DPD inkludert Packstationer, regnskap i DATEV eller lexoffice, og en ordrestatus som settes av serveren til leverandøren, ikke av at kunden tilfeldigvis kommer tilbake til takkesiden. Rekkefølgen er ikke tilfeldig: hvert ledd lenger ned i listen arver feilene fra leddet over hvis det ikke er riktig bygget.

#Betaling: Stripe DE ved siden av PayPal og SEPA

Stripe er asynkront, ikke et skjema. Payment Element laster etter at siden er klar, 3DS kan utløses midt i flyten, og webhook-bekreftelsen kommer uavhengig av redirect. Derfor implementeres gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer det Stripe krever og ingenting mer, mens fullføringen skjer i webhook-håndtereren. Ordren får payment_complete først når payment_intent.succeeded er bekreftet.

PayPal går ved siden av, ikke i stedet for. PayPal og PayPal Pay Later dekker kunder som ikke vil bruke kort direkte, alltid med IPN/webhook-håndtering. 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.

SEPA for B2B. SEPA Lastschrift krever IBAN, mandatreferanse og tydelig informasjon i checkout. Mandatet lagres på ordren som en identifikator fra betalingssystemet, ikke som fritekst. Avstemming skjer mot utbetaling fra Stripe eller bank, ikke mot enkeltordre isolert.

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

Fraktpriser hentes, de gjettes ikke. DHL og DPD gir pris og leveringstid per produkt og postnummer via API. Svaret kobles inn i kassen via woocommerce_package_rates, med volumvekt beregnet ut fra pakkens mål når den er høyere enn den faktiske vekten. Svarene mellomlagres i transienter per postnummer og vektklasse, fordi kassen ikke kan vente på et eksternt kall hver gang handlekurven oppdateres.

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.

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.

#Regnskap: DATEV eller lexoffice

Salget bokføres én gang, med riktig MwSt.-kode. DATEV og lexoffice har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MwSt.-kode i stedet for å sende en flat sats. Dokumentnummeret 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.

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å S-Bahn i Düsseldorf, lukke nettleseren, bytte til en annen app mens betalingen fullføres, eller ha mobilen i strømsparemodus. Redirecten tilbake til butikken er derfor ikke noe du kan regne med. 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 Stripe signing secret, 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 identifikator som allerede er lagret, blir forkastet. Uten dette gir gjentatte forsøk dobbel belastning, dobbel bokføring i DATEV og dobbelt kunde-e-post.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt 3DS, webhook som kommer to ganger, forsinket webhook, 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.

#WooCommerce i andre tyske byer

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

Etter lansering tar vedlikehold og support for WordPress i Düsseldorf oppdateringer, sikkerhetskopier og overvåking. Nordiske huber sammenligner ofte med vedlikehold i Stockholm og vedlikehold i København.

#Hvordan starter man et WooCommerce-prosjekt i Düsseldorf?

Trenger butikken din i Düsseldorf en kasse som tar Stripe DE på alvor, regner MwSt. og USt-IdNr. riktig for B2B, og tåler messe-trafikk uten å bryte sammen, ta kontakt for en uforpliktende gjennomgang. Jeg ser på dagens oppsett, finner den faktiske flaskehalsen og sier ærlig hva som bør gjøres først. Omfanget avtales individuelt etter revisjon, 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.