WooCommerce Utvikler i Amsterdam

En WooCommerce-butikk som selger til nederlandske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: iDEAL i kassen via Mollie, BTW på 21 prosent regnet riktig, og frakt via PostNL med hentested kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Amsterdam med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Nederland er et av Europas største e-handelsmarkeder per innbygger, og iDEAL dekker langt over halvparten av nettbetalinger i landet. En kasse uten iDEAL taper konverteringer på nederlandsk mobiltrafikk, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt i Amsterdam.

#WooCommerce-utvikling i Amsterdam

Amsterdam-markedet er kresent. Nederlandere er vant til kjappe kasser, iDEAL-knapp øverst, tydelig pris med BTW inkludert og levering til PostNL-pakkeboks eller hentested. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en nederlandsk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Mollie med iDEAL i kassen: iDEAL-knapp som primært betalingsvalg, Bancontact for belgiske kunder, kort og Apple Pay ved siden av, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• BTW-oppsett for nederlandsk handel: 21 prosent standardsats, redusert sats på næringsmidler og bøker, fritak der det gjelder, og priser vist inkludert BTW slik nederlandske forbrukere forventer
• Frakt med PostNL og DHL: fraktsoner innen Nederland og til resten av EU, prisregler basert på vekt og volum, pakkeboks og hentested som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• Tospråklig NL/EN-butikk: WPML eller Polylang for WooCommerce med riktig hreflang, separate URL-strukturer per språk, og checkout-felt tilpasset nederlandsk postnummerformat og telefonnummer
• EU-hosting med databehandling innen EØS: servere i EU, databehandleravtale som dekker WooCommerce-ordredata, og arkitektur som tåler ettersyn fra Autoriteit Persoonsgegevens (AP)
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller markedsplass, med autentisering og idempotente betalingsstier

#Hvorfor nederlandske betalings- og fraktvalg styrer arkitekturen

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

Frakt er den andre fellen. En nederlandsk kunde forventer å velge et PostNL-hentested eller en pakkeboks 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 nederlandske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Amsterdam

Amsterdam er Nederlands tyngste e-handels- og teknologimiljø. B. Amsterdam på Sloterdijk huser over 200 bedrifter, og området rundt Zuidas trekker til seg internasjonale merkevarer som bruker Nederland som inngangsport til EU. Selskaper som bol.com, Coolblue og Adyen har sitt utspring i dette økosystemet. For en netthandler betyr det at konkurransen om nederlandske kunder er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt.

Kundene våre i Amsterdam spenner fra nisjebutikker som selger direkte til forbruker, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode og unngå plattformgebyrer. Fellesnevneren er at de trenger en butikk som tar iDEAL på alvor, regner BTW riktig og lar dem styre frakten 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, et betalingstillegg slutter å bli vedlikeholdt, eller AP stiller spørsmål om databehandlingen. 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 (Mollie, iDEAL, kort), PostNL-fraktsoner, BTW-regler, NL/EN-språkstruktur 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, PostNL- og DHL-fraktsoner med hentestedslogikk, BTW-håndtering, EU-hosting 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 test-iDEAL og testkort på hver gateway, refusjon og delvis refusjon, 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 Amsterdam-butikker

• iDEAL 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 via Mollie.
• Treg kasse på mobil. En butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før iDEAL-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.
• BTW regnet feil på tvers av NL og EU. En butikk som solgte både innenlands og til resten av EU blandet sammen nederlandsk BTW og OSS-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og fikk grenseoverskridende salg merket riktig mot Intrastat-rapportering.

#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 Mollie med iDEAL, Bancontact og kort, alltid med 3D Secure på kortbetalinger. Hosting ligger innen EU/EØS med databehandling som tåler GDPR-ettersyn. 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 iDEAL på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det nederlandske kunder forventer fra PostNL og DHL, BTW 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.

For nederlandske nettbutikker betyr det i praksis at kundedata fra iDEAL- og kortbetalinger, samt navn og adresse for frakt, behandles og lagres slik regelverket krever. Autoriteit Persoonsgegevens (AP) er den nederlandske tilsynsmyndigheten, og butikker som selger til nederlandske forbrukere bør ha dokumentasjon som tåler ettersyn: behandlingsgrunnlag, datalagring innen EØS, og sletting av kundedata på forespørsel. Vi bygger dette inn i arkitekturen, ikke som et ettertankevedlegg.

#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 Mollie), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som iDEAL-knappen. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Amsterdam-butikker stiller oss

Setter dere opp Mollie med iDEAL i kassen? Ja. Vi integrerer iDEAL som primært betalingsvalg, Bancontact, kort og Apple Pay 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 BTW og OSS riktig? Ja. Vi setter 21 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert BTW slik nederlandske forbrukere forventer, og skiller OSS-flyten for grenseoverskridende salg innen EU fra ordinær innenlands BTW.

Hvilke fraktløsninger støtter dere? PostNL og DHL, med fraktsoner, prisregler etter vekt og volum, hentested og pakkeboks som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Trenger vi EU-hosting? For nederlandske nettbutikker som håndterer personopplysninger anbefaler vi hosting innen EU/EØS. Det forenkler GDPR-samsvar og gjør det enklere å dokumentere databehandlingen overfor AP ved ettersyn.

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

#Integrasjoner en nederlandsk nettbutikk faktisk trenger

En nederlandsk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Mollie og iDEAL, frakt med PostNL inkludert hentesteder, regnskap i Exact Online eller Twinfield, 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: Mollie og iDEAL ved siden av kort

iDEAL er en bank-redirect, ikke et skjema. Integrasjonen bygges mot Mollie Payments API der kunden velger bank, redirectes til nettbanken og bekrefter. 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 webhook-håndtereren. Ordren får payment_complete først når Mollie har bekreftet.

Reserver nå, trekk ved forsendelse. Nederlandsk praksis for varesalg er å reservere beløpet ved kjøp og trekke det når varen sendes. Det betyr at integrasjonen må skille tydelig mellom autorisasjon, belastning, delvis belastning, annullering og refusjon, og at hver av disse må kunne utløses både fra Woo-admin og fra en bakgrunnsjobb. Delvis belastning er en vanlig kilde til avvik når en ordre sendes i to forsendelser.

Bancontact og kort går ved siden av, ikke i stedet for. Mollie dekker iDEAL, Bancontact, kort og Apple Pay i én gateway, men hver metode har egne statuskoder og webhook-formater. Ordren må lagre i metadata hvilken betalingsmetode som eide betalingen og hvilken Mollie-referanse den bruker. Uten dette blir refusjon fra admin et gjettespill.

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: PostNL og DHL med hentesteder

Fraktpriser hentes, de gjettes ikke. PostNL Shipping 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 PostNL-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.

#Regnskap: Exact Online eller Twinfield

Salget bokføres én gang, med riktig BTW-kode. Både Exact Online og Twinfield har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig BTW-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. Mollie 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.

B2B og offentlig sektor betyr e-faktura. Selger butikken til offentlige oppdragsgivere i Nederland, skal fakturaen sendes elektronisk via Peppol-nettverket, med KvK-nummer på mottakeren. Det er en egen flyt i kassen: felt for organisasjonsnummer, validering, og et annet dokumentløp enn forbrukersalget.

Oppbevaringsplikt og audit trail. Bokføringspliktig dokumentasjon skal oppbevares i syv år etter regnskapsårets slutt i Nederland. I praksis betyr det at butikken ikke er regnskapssystemet: WooCommerce er kilden, Exact eller Twinfield er arkivet, og integrasjonen må overføre nok informasjon til at arkivet er komplett uten oppslag i databasen til nettbutikken.

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. En regnskapstjeneste 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å metroen i Amsterdam, lukke bankappen, 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 Mollies 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 delt hemmelighet, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb. Mollie 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 regnskapet 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 Mollie 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 iDEAL-betaling i bankappen, webhook som kommer to ganger, webhook som kommer i feil rekkefølge, forsinket webhook, frakt-API som svarer for sent, og regnskaps-API som avviser dokumentet. Hver av disse skal ende i en ordre med riktig status og en linje i loggen.

#WooCommerce i andre nederlandske og nærliggende byer

Trenger du WooCommerce-hjelp utenfor Amsterdam, gjelder de samme nederlandske kravene til iDEAL, BTW og PostNL-frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Rotterdam og WooCommerce-utvikler i Antwerpen for hvordan oppsettet tilpasses der.

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

#Andre europeiske byer

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

• Rotterdam - WooCommerce-utvikler i Rotterdam
• Paris - WooCommerce-utvikler i Paris
• Berlin - WooCommerce-utvikler i Berlin
• Brussel - WooCommerce-utvikler i Brussel

#Start et WooCommerce-prosjekt i Amsterdam

Trenger butikken din i Amsterdam en kasse som tar iDEAL på alvor, regner BTW 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. Prisen settes individuelt etter omfang, og du får oversikten skriftlig før arbeidet starter.

For butikker og nettsteder som trenger løpende oppfølging etter lansering, er inngangen vedlikehold og support i Amsterdam.