WooCommerce Utvikler i Frankfurt am Main

En WooCommerce-butikk som selger B2B til tyske bedrifter fra Frankfurt må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Stripe med tysk merchant-konto og SEPA der det passer, MwSt med USt-IdNr-validering og netto-priser for bedriftskunder, og personvern som tåler en gjennomgang fra BfDI uten at kassen blir et etterpåkladd. Vi bygger og rydder opp i WooCommerce for bedrifter i Frankfurt am Main med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Frankfurt er kontinentaleuropas finansielle tyngdepunkt. TechQuartier og Frankfurt FinTech Hub samler bank- og fintech-miljøer som forventer sporbarhet i ordreflyten, skriftlige databehandleravtaler og en kasse som ikke setter ordre til betalt på redirect. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Frankfurt

Frankfurt-markedet er kresen på B2B-e-handel. Tyske innkjøpere forventer netto-priser, korrekt MwSt-behandling av omvendt avgiftsplikt ved gyldig USt-IdNr, faktura som betalingsmetode der avtalen krever det, og en checkout som tåler revisjon uten at utvikleren må forklare hvorfor ordrestatus ble satt manuelt. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en tysk B2B-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: kort med 3D Secure, SEPA Direct Debit der avtalen tillater det, Apple Pay og Google Pay, med testmatrise for autorisasjon, belastning, refusjon og delvis refusjon mot Stripe testmiljø
• B2B-kasse med WooCommerce B2B eller tilsvarende: rollebaserte priser, minimumsordre, innkjøpsordrenummer som obligatorisk felt, netto-priser for bedriftskunder og MwSt-behandling av omvendt avgiftsplikt når USt-IdNr valideres mot VIES
• MwSt-oppsett for tysk handel: standardsats og reduserte satser per produktgruppe, OSS for EU-salg utenfor Tyskland der det gjelder, og tydelig skille mellom B2C og B2B i samme butikk
• Klarna og PayPal ved siden av Stripe der trafikken krever det, med riktig rekkefølge i kassen og egne runbooks per gateway
• Frakt med DHL, DPD eller Hermes: fraktsoner, prisregler basert på vekt og volum, og fraktsedler/sporing koblet mot ordrebehandlingen
• ERP- og regnskapskoblinger mot DATEV, Lexware eller SAP Business One, med ordreoverføring via Action Scheduler og idempotens slik at dobbel synkronisering ikke gir dobbelt salgsbilag
• Utvidelser av WooCommerce REST API for hodeløs storefront, partnerportal eller intern bestillingsapp, med autentisering og idempotente betalingsstier

#Hvorfor tysk betaling og B2B-kasse styrer arkitekturen

I de fleste WooCommerce-prosjekter for Frankfurt er det ikke produktkatalogen som er vanskelig, det er kassen og etterlevelsen. Stripe oppfører seg forutsigbart teknisk, men tysk B2B-handel legger ekstra lag på toppen: USt-IdNr må valideres før MwSt fjernes, faktura som betalingsmetode krever egen ordrestatus og purring, og SEPA-mandater må lagres med referanse som tåler chargeback-spor. Vi har sett butikker der omvendt avgiftsplikt ble aktivert på feil kundegruppe fordi VIES-sjekken kjørte asynkront etter at ordren allerede var opprettet. Den typen feil fanges bare med ende-til-ende-QA på selve B2B-stien.

Personvern er den andre fellen. BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) forventer at samtykke, formålsbegrensning og sletting er dokumentert, ikke bare at det står en cookie-banner-plugin på forsiden. Når butikken håndterer bedriftskontakter, ordrehistorikk og betalingsreferanser fra Stripe, må databehandleravtale, underleverandørliste og lagringstid være sporbar i runbooken. Vi bygger det inn i arkitekturen, ikke som et vedlegg etter lansering.

#Markedet og miljøet i Frankfurt

Frankfurt er hjemsted for TechQuartier og Frankfurt FinTech Hub. DE-CIX i regionen gjør at mange selskaper hoster tett på infrastrukturen de selger til, men WooCommerce-butikken må fortsatt tåle revisjon: hvem behandler betalingsdata, hvor ligger ordreloggen, og hvordan slettes kundedata på forespørsel. Kundene våre i Frankfurt spenner fra fintech-leverandører som selger programvare og lisenser B2B, til industribedrifter i Rhein-Main-regionen som åpner grossistportal på WooCommerce for å slippe telefonbestillinger.

Mange av disse butikkene har vokst organisk: et tema fra en kjøpt mal, B2B-tillegg som overlapper med standard Woo-funksjoner, og en kasse som ble lappet sammen da MwSt-reglene eller Stripe-kontoplanen endret seg. Det fungerer helt til volumet øker, en gateway-webhook slutter å komme fram, eller revisjonen spør hvorfor personopplysninger ligger i autoloaded options. Da trengs det opprydding i arkitekturen: egen plugin for B2B-logikk, fjerne tillegg som dupliserer hverandre, og gjøre ordrestatus forutsigbar igjen. Vi tar den typen refaktorering uten å bygge alt på nytt, så lenge WooCommerce er riktig plattform. 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, B2B-felt 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 regler, MwSt og USt-IdNr-logikk, 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-SEPA på hver gateway, refusjon og delvis refusjon, B2B-fakturaflyt, 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 Frankfurt-butikker

• Stripe-webhook nådde ikke produksjon. En B2B-butikk markerte ordrer betalt på redirect tilbake fra Stripe Checkout i stedet for på payment_intent.succeeded. Vi flyttet bekreftelsen til signert webhook, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og åpnet endepunktet for Stripe IP-range uten sidecache.
• USt-IdNr og omvendt avgiftsplikt feil. En grossist aktiverte null MwSt for alle bedriftskunder uten VIES-validering. Vi koblet validering før checkout fullføres, logget VIES-svar på ordren, og skilte B2C-flyt fra B2B-flyt i samme butikk.
• Treg kasse på mobil. En butikk med tungt tema og mange tillegg hadde merkbar forsinkelse før betalingsknappen var klikkbar. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kall og autoloaded options som var skyld i mesteparten, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.

#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 med tysk merchant-konto der kunden har det, supplert med Klarna, PayPal og SEPA avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot DATEV eller lager, 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 bekrefter ordrer på Stripe-webhook, ikke på redirect, B2B-felt som tåler VIES og omvendt avgiftsplikt, fraktvalg som matcher det tyske markedet, personvern dokumentert for BfDI-kontekst, 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, personvern og BfDI

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 med Stripe og andre underleverandører, register over behandlingsaktiviteter der kunden trenger det, og personvern bygget inn i arkitekturen. For tyske B2B-butikker betyr BfDI-praksis i tillegg at sletting og dataportabilitet må kunne demonstreres uten manuell databasejobb, og at logging av hvem som så hvilken ordre er avklart skriftlig.

#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 betalingsfelt. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Frankfurt-butikker stiller oss

Setter dere opp Stripe for tysk merchant-konto? Ja. Vi konfigurerer Stripe DE med kort, SEPA 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 MwSt og USt-IdNr riktig? Ja. Vi setter standardsats og reduserte satser per produktgruppe, skiller B2C og B2B, validerer USt-IdNr mot VIES før omvendt avgiftsplikt aktiveres, og dokumenterer OSS der butikken selger til andre EU-land.

Hva med BfDI og GDPR? Vi kartlegger behandlingsgrunnlag, samtykke der det kreves, underleverandører (Stripe, hosting, e-post), lagringstid og slettingsprosedyre. Runbooken skal tåle at en DSB eller intern revisjon spør hvor ordredata ligger og hvordan de slettes.

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

#Integrasjoner en tysk B2B-netthandel faktisk trenger

En tysk B2B-butikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Stripe DE og eventuelt SEPA, frakt med DHL eller DPD, regnskap i DATEV eller Lexware, 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 og SEPA

Stripe er webhook-drevet, ikke redirect-drevet. Integrasjonen bygges som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer det Stripe trenger (Payment Intent, Checkout Session eller Setup Intent for SEPA), mens fullføringen skjer i webhook-håndtereren signert med Stripe sitt endpoint secret. Ordren får payment_complete først når Stripe har bekreftet hendelsen.

SEPA krever mandatreferanse. For gjentakende trekk eller faktura med senere belastning lagres mandate ID og kunde-referanse på ordren og i brukermeta der avtalen krever det. Refusjon og delvis refusjon må dokumenteres i runbooken med Stripe Dashboard og Woo-admin som to innganger som begge skriver samme ordrehistorikk.

B2B-faktura er en egen betalingsmetode. Når bedriftskunder betaler på faktura med betalingsfrist, opprettes ordren med status som venter på betaling, purres via Action Scheduler, og kobles til regnskap når betalingen registreres manuelt eller via bankavstemming. Dette må ikke blandes med Stripe-kortflyten i samme statusmaskin uten tydelige regler.

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

Fraktpriser hentes, de gjettes ikke. DHL og DPD tilbyr API for pris og leveringstid per pakke 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.

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.

#Regnskap: DATEV og Lexware

Salget bokføres én gang, med riktig MwSt-kode. DATEV og Lexware har API eller filformat som regnskapsføreren forventer. Integrasjonen oppretter kunde og salgsdokument, mapper hver produktgruppe til riktig MwSt-kode, og skriver dokumentnummer tilbake på ordren. Eksistensen av dette nummeret hindrer dobbeltbokføring ved en ny kjøring.

B2B og omvendt avgiftsplikt må følge med. Når USt-IdNr er validert og omvendt avgiftsplikt gjelder, skal salgsbilaget reflektere det som regnskapsføreren forventer, ikke bare vise null MwSt i Woo uten begrunnelse på fakturaen.

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 lukke nettleseren, miste dekning på S-Bahn i Frankfurt, eller bytte app mens betalingen fullføres. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Stripe-webhooken er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser signaturen først. Webhook-endepunktet skal verifisere Stripe-signatur med endpoint secret, svare raskt med HTTP 200, og gjøre det tunge arbeidet i en bakgrunnsjobb. Stripe prøver på nytt når svaret drøyer.

Idempotens lagres, den antasses ikke. Hver Stripe event ID lagres når hendelsen er behandlet, og duplikater forkastes. Uten dette gir gjentatte forsøk dobbel ordre, dobbel bokføring og dobbelt kunde-e-post.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter Payment Intent-status for ordrer som har stått ventende lenger enn et definert vindu, og retter opp der webhook aldri kom fram. Jobben kjøres via ekte systemcron med DISABLE_WP_CRON satt.

#WooCommerce i andre tyske byer

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

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

#Start et WooCommerce-prosjekt i Frankfurt

Trenger butikken din i Frankfurt en B2B-kasse med Stripe DE, korrekt MwSt og personvern som tåler dokumentasjon, 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 investeringen avtales individuelt etter kartlegging, og du får oversikten skriftlig før arbeidet starter.

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