WooCommerce Utvikler i Bordeaux

En WooCommerce-butikk som selger til franske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: CB (Carte Bancaire) via PayPlug eller Lyra i kassen, MVA på 20 prosent regnet riktig, og frakt via Colissimo, Chronopost eller Mondial Relay med hentested kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Bordeaux med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Franske netthandlere forventer checkout i EUR, CB som betalingsmetode og levering som matcher det de kjenner fra Cdiscount og Fnac. En kasse uten PayPlug eller tilsvarende CB-integrasjon taper konverteringer på fransk mobiltrafikk, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Bordeaux

Bordeaux-markedet er kresent. Kunder i Gironde er vant til raske kasser, CB-knapp øverst, tydelig fraktkostnad før betaling og pris med MVA inkludert. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en fransk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

Bordeaux er det økonomiske og kulturelle sentrum i Nouvelle-Aquitaine. I Chartrons sitter négociants, vinmerker og eksportører ved siden av Cité du Vin. I Darwin Eco-système og langs Bassins à Flot vokser digital-first merkevarer og food-tech-selskaper. Rundt Rue Sainte-Catherine møter gastronomi-, design- og livsstilsmerker en kjøpesterk lokal kundebase. Ved Port de Bordeaux kobles fulfilment, vinexport og B2B-distribusjon fysisk vareflyt med digital checkout.

#Hva vi faktisk bygger

• PayPlug og Lyra i kassen: CB via Carte Bancaire, Apple Pay, Google Pay, 3DS-logikk, webhook-håndtering og idempotens på ordrestiene, med testmatrise for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Alma og Klarna ved siden av CB for Pay Now og Pay Later, med riktig rekkefølge i kassen for fransk trafikk og separat webhook-testing per gateway
• MVA-oppsett for fransk handel: 20 prosent normalsats, reduserte satser for definerte varegrupper, reverse charge for gyldig EU-MVA-nummer validert mot VIES, og priser vist inkludert MVA slik franske forbrukere forventer
• Colissimo, Chronopost og Mondial Relay: fraktsoner for postnummer 33000 til 33800 og omegn (Mérignac, Pessac, Talence), prisregler basert på vekt og volum, hentested/Relais som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• CNIL-tilpasset samtykke: cookie-banner før ikke-essensielle skript (Axeptio, Tarteaucitron eller tilsvarende), granulært opt-in, politique de confidentialité og databehandleravtaler med leverandører
• Vin- og gastronomie-handel: aldersverifisering ved checkout, appellasjons-metadata på produkter, fraktregler per destinasjonsland og dokumentert audit-trail i admin
• B2B-funksjonalitet for leverandører i Mérignac og logistikkmiljøet: netto-priser, minste ordremengder, tilbudsforespørsel med godkjenning og dedikerte bedriftsportaler
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor franske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Bordeaux er det ikke produktkatalogen som er vanskelig, det er kassen. PayPlug og Lyra oppfører seg ikke som et generisk kortskjema: redirect-flyten, 3DS-håndteringen og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før gatewayen faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte CB-betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Frakt er den andre fellen. En fransk kunde forventer å velge hentested hos Mondial Relay eller Colissimo-punkt 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 franske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Bordeaux

French Tech Bordeaux og Darwin Eco-système gir et aktivt tech-miljø, men Bordeaux er ikke Paris fintech. Her handler e-handel ofte om vin, logistikk og B2B-leveranser. En négociant i Chartrons trenger checkout som håndterer appellasjonsdata og eksportregler. En merkevare fra Bassins à Flot trenger medierik katalog uten at checkout brekker under trafikkspitser etter Vinexpo eller en influencerkampanje. En B2B-leverandør i Mérignac trenger netto-priser og ERP-kobling, ikke en fargerik handlekurv.

Kundene våre i Bordeaux spenner fra vinmerker som selger direkte til forbruker og eksport, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar CB på alvor, regner MVA 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 CNIL stiller spørsmål ved cookie-banneret etter en temoppdatering. 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 (PayPlug, Lyra, Alma, PayPal), fraktsoner mot Colissimo og Mondial Relay, MVA-regler, CNIL-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 Relais-logikk, MVA- og reverse-charge-håndtering, og koblinger mot regnskap (Sage, Cegid, EBP), 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-CB 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 Bordeaux-butikker

• PayPlug eller Lyra 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.
• Treg kasse på mobil. En vinbutikk fra Chartrons med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før CB-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.
• Colissimo og Mondial Relay ikke riktig satt opp. Fraktsoner for 33000 til 33800 og omegn manglet, og Relais-valg ble lagret som fritekst i stedet for leverandørens identifikator. Vi koblet frakt-API mot woocommerce_package_rates, lagret Relais-ID på ordren og koblet sporingsnummer inn i forsendelsesvarselet.
• CNIL og cookie-banner etter temoppdatering. En temoppdatering deaktiverte skriptblokkering slik at Google Analytics og Meta Pixel lastet før samtykke. Vi satte opp kvartalsvis gjennomgang av banner og tags, og dokumenterte endringer i runbooken.

#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 PayPlug, Lyra, Alma og PayPal avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager, regnskap eller fulfilment ved Port de Bordeaux, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen.

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.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som tar CB via PayPlug eller Lyra på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det franske kunder forventer fra Colissimo og Mondial Relay, MVA og CNIL-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, RGPD og CNIL

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 RGPD-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen.

For franske nettbutikker betyr det i praksis at CNIL (Commission Nationale de l’Informatique et des Libertés) er tilsynsmyndighet. Cookie-banner må blokke ikke-essensielle skript før samtykke, politique de confidentialité må være teknisk korrekt koblet, og ved personvernbrudd har dataansvarlig 72 timer til å vurdere melding til CNIL. Vi leverer teknisk tidslinje og logger; rettslig vurdering ligger hos kunden og deres rådgivere. Hosting i EU med tydelig databehandleravtale er standard, ikke tilvalg.

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

Vinbutikker og medierike kataloger fra Chartrons trenger fragment-caching med unntak for handlekurv og checkout, lazy loading av produktgallerier og CDN foran statiske ressurser. Uten dette kollapser butikken nettopp når Vinexpo eller julesalg gir trafikkspitser.

#Spørsmål Bordeaux-butikker stiller oss

Setter dere opp PayPlug og Lyra i kassen? Ja. Vi integrerer CB via Carte Bancaire, Apple Pay og Google 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 fransk MVA og reverse charge riktig? Ja. Vi setter 20 prosent normalsats og reduserte satser der de gjelder, viser priser inkludert MVA slik franske forbrukere forventer, og skiller reverse-charge-flyten for gyldig EU-MVA-nummer validert mot VIES fra ordinær B2C-MVA.

Hvilke fraktløsninger støtter dere? Colissimo, Chronopost og Mondial Relay, med fraktsoner for Bordeaux og Gironde, prisregler etter vekt og volum, Relais som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Hva med CNIL og cookies? Vi setter opp samtykkebanner som blokkerer ikke-essensielle skript før opt-in, dokumenterer underprosessorer og sørger for at temoppdateringer ikke deaktiverer blokkeringen uten at noen merker det. Dette er teknisk scope, ikke juridisk rådgivning.

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 Bordeaux? Ja. Vi har tyngdepunktet i Bordeaux-miljøet, men leverer til netthandlere i hele Frankrike og til eksportører som selger fra Gironde til resten av EU.

#Integrasjoner en fransk nettbutikk faktisk trenger

En fransk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med PayPlug eller Lyra og CB, frakt med Colissimo eller Mondial Relay inkludert Relais, regnskap i Sage, Cegid eller EBP, 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: PayPlug og Lyra ved siden av CB

CB er standard checkout-sti i Frankrike. Integrasjonen bygges som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect og ingenting mer, mens fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når PayPlug eller Lyra har bekreftet via webhook.

Reserver nå, belast ved forsendelse. Fransk praksis for varesalg er ofte å autorisere beløpet ved kjøp og belaste 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.

Lyra og PayPlug deler mønsteret, ikke identisk API. 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.

Alma og Klarna går ved siden av, ikke i stedet for CB. Pay Now, Pay Later og avbetaling må testes separat. Webhooks for betalingsbekreftelse og refusjoner kjører idempotent; ordrestatus følger gatewayen, ikke takkesiden.

#Frakt: Colissimo, Chronopost og Mondial Relay

Fraktpriser hentes, de gjettes ikke. Colissimo og Chronopost gir pris og leveringstid per produkt og postnummer, autentisert med API-nøkkel fra leverandøren. 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.

Relais er et eget datafelt. Kunden velger et konkret utleveringssted eller en pakkeboks i kassen, og valget må lagres på ordren som en identifikator fra Mondial Relay, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren. Skrives den som en adresse i et notatfelt, må lageret i Mérignac eller ved havnen slå den opp manuelt.

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: Sage, Cegid eller EBP

Salget bokføres én gang, med riktig MVA-kode. Sage, Cegid og EBP har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MVA-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. PayPlug, Lyra og Stripe 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 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å TGV-en til Paris, lukke nettleseren, bytte 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 PayPlug eller Lyra er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser først, kvitter raskt, jobb etterpå. Callback-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 regnskapet og dobbelt kunde-e-post.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter status fra leverandøren 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.

#TVA, fakturaer og eksport fra Bordeaux

Fransk normalsats for MVA er 20 prosent. Reduserte satser gjelder for definerte varegrupper, som visse næringsmidler eller bøker. I butikken betyr det vedlikeholdte avgiftsklasser, permanent lagrede avgiftsposter på ordren og ingen etterberegning i regnskapet.

B2B reverse charge krever gyldig EU-MVA-nummer. Ekstra felt i checkout, validering mot VIES, lagring av resultat og tidsstempel på ordren. Ved mislykket validering belastes ordinær MVA, og valideringen gjentas asynkront.

Eksport til EU bruker OSS-prosedyren når terskelverdiene nås. For Bordeaux-merker som selger parallelt i Tyskland eller Spania gjelder separate rapporteringsplikter. I butikken betyr det separat avgiftslogikk per destinasjonsland, ikke én global sats på alle adresser.

Overlevering til regnskap er et grensesnitt. Fortløpende fakturanummer, obligatoriske opplysninger etter fransk regelverk, eksport til Sage eller Cegid med avstemte kontoer, og avstemming av samleutbetalinger fra PayPlug, Lyra eller Stripe. Om et selskap er rapporteringspliktig, avklarer skatterådgiver; vi bygger den tekniske stien.

#WooCommerce i andre franske byer

Trenger du WooCommerce-hjelp utenfor Bordeaux, gjelder de samme franske kravene til CB, MVA og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Paris, WooCommerce-utvikler i Lyon og WooCommerce-utvikler i Marseille for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Bordeaux oppdateringer, sikkerhetskopier og overvåking. Nordiske huber sammenligner ofte med vedlikehold i Oslo og vedlikehold i Stockholm.

#Start et WooCommerce-prosjekt i Bordeaux

Trenger butikken din i Bordeaux, Mérignac eller Gironde en kasse som tar PayPlug eller Lyra på alvor, regner fransk MVA riktig og lar deg styre Colissimo-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. Omfanget avtales individuelt, 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.