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

#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. Vi 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. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

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.

#Markedet og miljøet 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 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.

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

#Typiske oppdrag fra Düsseldorf-butikker

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

Vi kjører WooCommerce på PHP 8.2 eller nyere, med object caching (Redis) der trafikken forsvarer det, og CDN foran statiske ressurser. 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

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi 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å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 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. Vi 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. 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 Payment Element), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som betalingsfeltet. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Düsseldorf-butikker stiller 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 en klar deling mellom egen plugin og tema, slik at butikken overlever Woo-oppdateringer.

Jobber dere med butikker utenfor Düsseldorf? Ja. Vi 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: hver kobling nedover i listen arver feilene fra den over hvis den første 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 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.

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. 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 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 allerede lagret identifikator forkastes. 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.

#Start 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. 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 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 i Düsseldorf.