WooCommerce Utvikler i Lisboa

En WooCommerce-butikk som selger til kunder i Lisboa og Portugal må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: MB WAY og Multibanco i kassen, IVA beregnet riktig for portugisiske og EU-kunder, og personvern som oppfyller CNPDs forventninger til samtykke og databehandling. Vi bygger og rydder opp i WooCommerce for bedrifter i Lisboa med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Portugal er et av de raskest voksende e-handelsmarkedene i Sør-Europa, og Lisboa er både turistdestinasjon og tech-hub. MB WAY brukes av millioner av portugisere, og en kasse uten mobilbetaling taper konverteringer på lokal trafikk. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Lisboa

Lisboa-markedet er modent. Portugisiske netthandlere er vant til raske kasser, MB WAY-knapp på mobil, Multibanco-referanse for de som betaler senere, og tydelig IVA i henhold til lokal forbrukerlovgivning. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en lokal kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• MB WAY og Multibanco i kassen via Ifthenpay, EuPago eller Easypay: app-betaling på mobil, referansebetaling med ventende ordrestatus til betaling bekreftes, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Stripe og kort ved siden av lokale gatewayer der butikken selger internasjonalt, med riktig rekkefølge i kassen for portugisisk trafikk og testkort-matrise per gateway
• IVA-oppsett for portugisisk handel: 23 prosent standardsats, redusert sats på næringsmidler og bøker, fritak der det gjelder, og OSS-håndtering for EU-salg utenfor Portugal
• Sertifisert fakturering mot AT-godkjent programvare (InvoiceXpress, Moloni, Vendus): ordre overføres til faktureringssystemet med ATCUD og QR-kode, ikke improvisert i temaet
• Flerspråklig storefront: portugisisk (PT), engelsk (EN) og fransk (FR) der markedet krever det, med hreflang, uavhengige produktbeskrivelser per språk og kasseflyt tilpasset hvert marked
• Frakt med CTT, CTT Expresso og DPD: fraktsoner innen Portugal og til EU, prisregler basert på vekt og volumvekt, og fraktsedler/sporing koblet mot ordrebehandlingen
• CNPD-tilpasset personvern: samtykkehåndtering, cookie-banner med granulært valg, databehandleravtaler og personvernerklæring bygget inn i arkitekturen
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor portugisiske betalings- og fraktvalg styrer arkitekturen

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

Multibanco er den andre fellen. En portugisisk kunde forventer en referanse de kan betale i homebanking, og ordren forblir ventende til betalingen kommer, noen ganger timer eller dager senere. Butikken må håndtere den ventende tilstanden uten å frigjøre lager for tidlig eller kansellere for tidlig. E-posten til kunden må skille tydelig mellom betalt ordre og ordre som venter på Multibanco-betaling.

Frakt er den tredje. En portugisisk kunde forventer CTT eller CTT Expresso med sporingsnummer i e-posten, ikke bare «standard frakt». Turistbedrifter som selger opplevelser og regionale produkter trenger i tillegg fraktregler som håndterer sesongtopper uten at kassen kollapser under sommertrafikk.

#Markedet og miljøet i Lisboa

Lisboa er Portugals kommersielle og teknologiske tyngdepunkt. Factory Lisbon i Beato samler startups, coworking og tech-selskaper som betjener både det lokale markedet og eksport til resten av EU. Web Summit holdes i Lisboa, og byen tiltrekker digital nomads som forventer nettbutikker som fungerer på mobil og på engelsk. Turistnæringen i Alfama, Baixa og langs Tagus-elven selger opplevelser, regionale produkter og gaveesker med sesongbasert trafikk som topper seg om sommeren.

Kundene våre i Lisboa spenner fra D2C-merkevarer i mote og livsstil som eksporterer til Frankrike og Storbritannia, til turistbedrifter som selger opplevelser og lokale produkter på tre språk, til fintech-startups som trenger WooCommerce-integrasjoner med Multibanco og MB WAY. Fellesnevneren er at de trenger en butikk som tar portugisiske betalingsmetoder på alvor, regner IVA riktig, oppfyller CNPDs forventninger og tåler sesongtopper uten å måtte skrive om arkitekturen.

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 i høysesongen, et betalingstillegg slutter å bli vedlikeholdt, eller CNPD stiller spørsmål ved samtykkehåndteringen. 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.

WordPress Lisboa meetup er det lokale fellesskapet der utviklere møtes og deler erfaringer. Vi følger det portugisiske markedet tett, inkludert endringer i AT-krav til fakturering og CNPDs veiledninger om cookies og markedsføring.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Multibanco, MB WAY, Stripe), fraktsoner mot CTT, IVA-regler, CNPD-krav 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 leveringslogikk, IVA- og OSS-håndtering, kobling mot sertifisert fakturering, og integrasjoner 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-MB WAY, Multibanco-referanse 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 Lisboa-butikker

• MB WAY markerte ordrer betalt på redirect. En D2C-merkevare i Santos markerte ordrer fullført når kunden kom tilbake fra appen, ikke når webhook bekreftet betalingen. Vi flyttet bekreftelsen til callback-håndtereren, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon.
• Multibanco-referanse uten ventende ordrestatus. En turistbutikk som solgte gaveesker genererte Multibanco-referanser, men markerte ordren som betalt med en gang. Lageret frigjorde varer som aldri ble betalt. Vi satte ordren i ventende status til webhook bekreftet betaling, med tydelig e-post til kunden om at ordren venter på betaling, og automatisk kansellering etter definert tidsvindu.
• Eksport til Frankrike og Storbritannia uten riktig IVA. En produsent av korkprodukter solgte til EU og Storbritannia, men blandet portugisisk IVA og OSS-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og destinasjonsland, og koblet ordre mot Moloni for sertifisert fakturering med ATCUD.
• Treg kasse i sommerhøysesong. En opplevelsesbedrift i Alfama hadde flere sekunders forsinkelse på kassesiden akkurat når turisttrafikken toppet seg. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor, fant cart-fragment-kallene og autoloadede options som var skyld i mesteparten, separerte cachebare produktsider fra sesjonsavhengig kasse, og fjernet flaskehalsene én etter én.

#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 Ifthenpay, EuPago, Easypay eller Stripe avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager, fakturering eller frakt-API-er, 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 MB WAY og Multibanco på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det portugisiske kunder forventer fra CTT, IVA og sertifisert fakturering 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 portugisiske nettbutikker betyr det i praksis at CNPD (Comissão Nacional de Proteção de Dados) er tilsynsmyndigheten som vurderer om samtykke, informasjonsplikt og datalagring er i orden. CNPD har publisert veiledninger om cookies, markedsføring og behandling av personopplysninger i e-handel. Vi dokumenterer behandlingsgrunnlag for kundedata fra MB WAY- og kortbetalinger, navn og adresse for frakt, og eventuelle markedsføringscookies. Cookie-banneret må gi reelt valg, ikke bare et «Godta alt»-knapp uten avvisning. Personvernerklæringen må nevne databehandlere (Ifthenpay, EuPago, CTT) og formålet med hver behandling. Dette er ikke juridisk rådgivning, men teknisk implementering av det regelverket krever.

For fintech- og turistnære bedrifter i Lisboa spiller NIS2- og DORA-forventninger til leverandørkjeder en rolle, spesielt når tyske eller britiske partnere vurderer dataoverføringer og dokumentasjonskrav. Vi dokumenterer sikkerhetsgrunnlinjen skriftlig i overleveringen.

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

Turistbedrifter med sesongtopper får i tillegg cache-arkitektur som skiller anonyme produktsider (cachebare) fra kasse og handlekurv (alltid til origin), slik at sommertrafikken ikke tvinger opp serverdimensjonering hele året.

#Spørsmål Lisboa-butikker stiller oss

Setter dere opp MB WAY og Multibanco i kassen? Ja. Vi integrerer via Ifthenpay, EuPago eller Easypay, med app-betaling for MB WAY og referanseflyt for Multibanco, 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 portugisisk IVA og OSS riktig? Ja. Vi setter 23 prosent standardsats og reduserte satser der de gjelder, skiller OSS-flyten for salg til andre EU-land fra ordinær innenlands IVA, og dokumenterer reglene skriftlig for validering med regnskapsfører.

Trenger vi sertifisert fakturering? Over omsetningsgrensen AT setter, ja. WooCommerce alene utsteder ikke sertifiserte fakturaer med ATCUD og QR-kode. Vi kobler butikken mot InvoiceXpress, Moloni eller Vendus slik at hver betalt ordre overføres til faktureringssystemet automatisk.

Hvilke fraktløsninger støtter dere? CTT, CTT Expresso og DPD, med fraktsoner, prisregler etter vekt og volumvekt, 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 Lisboa? Ja. Vi har tyngdepunktet i Lisboa-miljøet, men leverer til netthandlere i hele Portugal og til portugisiske butikker drevet fra utlandet.

#Integrasjoner en portugisisk nettbutikk faktisk trenger

En portugisisk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Multibanco, MB WAY og kort, frakt med CTT og DPD, sertifisert fakturering via AT-godkjent programvare, 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: Multibanco, MB WAY og kort

MB WAY er en app-flyt, ikke et skjema. Integrasjonen bygges mot SIBS-nettverket via Ifthenpay, EuPago eller Easypay. Butikken oppretter en betaling, kunden bekrefter i mobilbanken, og bekreftelsen kommer asynkront. Alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect eller en ventetilstand, mens fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når leverandøren har bekreftet.

Multibanco genererer ventende ordrer. Referansebetalingen gir kunden et referansenummer og en entitet, og ordren forblir ventende til betalingen bekreftes, noen ganger timer eller dager senere. Butikken må håndtere den ventende tilstanden: ikke frigjøre lager for tidlig, sende tydelig e-post om at ordren venter, og kansellere automatisk etter definert tidsvindu hvis betalingen uteblir.

Kort går ved siden av, ikke i stedet for. Stripe dekker internasjonale kunder og de som foretrekker kort, alltid med 3D Secure. 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.

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: CTT, CTT Expresso og DPD

Fraktpriser hentes, de gjettes ikke. CTT og DPD 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.

Eksport krever egne fraktsoner. En produsent som sender korkprodukter eller vin til Frankrike og Storbritannia trenger fraktregler per destinasjonsland, med volumvekt for tunge esker og egne leveringstider. Turistbedrifter som sender lette gaveesker innen Portugal har andre regler. Vi skiller disse i fraktsonene i stedet for én flat tabell.

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, spesielt for turistbedrifter der kunden reiser videre etter kjøpet.

#Regnskap: Moloni, InvoiceXpress eller Vendus

Salget faktureres én gang, med riktig IVA-kode. InvoiceXpress, Moloni og Vendus har REST-API med token-basert autentisering. Integrasjonen overfører hver betalt ordre til faktureringssystemet, som utsteder sertifisert faktura med ATCUD og QR-kode. Nummeret på det opprettede dokumentet skrives tilbake på ordren, og eksistensen av dette nummeret er det som hindrer dobbeltfakturering ved en ny kjøring.

WooCommerce er ikke faktureringssystemet. AT krever sertifisert programvare for fakturering over omsetningsgrensen. WooCommerce håndterer katalog, handlekurv og kasse. Integrasjonen må overføre nok informasjon til faktureringssystemet uten at regnskapsføreren må slå opp i Woo-databasen.

IVA og OSS dokumenteres skriftlig. Reglene for innenlands salg, EU-salg med OSS og eksport utenfor EU settes per produktgruppe og destinasjonsland. Vi dokumenterer dem i runbooken og validerer med regnskapsfører, fordi feil IVA-antagelse viser seg ved kvartalsoppgjøret, ikke ved salget.

Synkronisering kjøres i kø. All overføring til fakturering legges på Action Scheduler med gjentatte forsøk ved feil, aldri synkront i kasseforespørselen. Et faktureringssystem som er nede, skal forsinke faktureringen, 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å trikkelen i Lisboa, lukke mobilbanken, bytte til en annen app mens MB WAY-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 Ifthenpay, EuPago eller Easypay 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 fakturering 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. Callback-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 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.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt MB WAY-betaling i mobilbanken, Multibanco-referanse som aldri betales, varsel som kommer to ganger, varsel som kommer i feil rekkefølge, forsinket varsel, frakt-API som svarer for sent, og fakturerings-API som avviser dokumentet. Hver av disse skal ende i en ordre med riktig status og en linje i loggen. Reaksjonstider ved feil i drift avtales skriftlig i vedlikeholdsavtalen.

#WooCommerce i andre portugisiske byer

Trenger du WooCommerce-hjelp utenfor Lisboa, gjelder de samme portugisiske kravene til Multibanco, MB WAY, IVA og CTT-frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Porto for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Lisboa oppdateringer, sikkerhetskopier og overvåking. Iberiske huber sammenligner ofte med WooCommerce-utvikler i Barcelona og WooCommerce-utvikler i Madrid.

#Andre iberske og nordiske byer

Samme WooCommerce-leveranse finnes i flere byer rundt Europa, med lokalt tilpasset betaling og MVA:

• Barcelona - WooCommerce-utvikler i Barcelona
• Madrid - WooCommerce-utvikler i Madrid
• Stockholm - WooCommerce-utvikler i Stockholm
• København - WooCommerce-utvikler i København

#Start et WooCommerce-prosjekt i Lisboa

Trenger butikken din i Lisboa en kasse som tar MB WAY og Multibanco på alvor, regner IVA riktig og tåler sesongtopper uten å kollapse, 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 en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon for WordPress.