WooCommerce Utvikler i Porto

En WooCommerce-butikk som selger til portugisiske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: MB WAY i kassen, IVA på 23 prosent regnet riktig, og frakt via CTT med sporing kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Porto med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

SIBS, som driver Multibanco og MB WAY, har sitt hovedkontor i Lisboa, men det er Porto som er inngangsporten til Douro-vinregionen og det nordlige turistmarkedet. En kasse uten MB WAY taper konverteringer på portugisisk mobiltrafikk, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Porto

Porto-markedet er kresent. Portugisiske netthandlere er vant til kjappe kasser, MB WAY-knapp øverst, Multibanco-referanse som alternativ, og tydelig pris med IVA inkludert. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en portugisisk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• MB WAY via Easypay, EuPago eller tilsvarende i kassen: app-flyt på mobil, hurtigkasse-knapp på produkt- og handlekurvside, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Multibanco-referansebetaling ved siden av MB WAY: generert referanse med utløpsdato, ordrestatus som venter til betalingen er bekreftet, og avstemming mot gatewayens rapport
• Kort (Visa/Mastercard via Stripe eller portugisisk acquirer) som tredje alternativ, med 3D Secure og riktig rekkefølge i kassen for portugisisk trafikk
• IVA-oppsett for portugisisk handel: 23 prosent standardsats, redusert sats på næringsmidler og bøker, fritak der det gjelder, og priser vist inkludert IVA slik portugisiske forbrukere forventer
• OSS-håndtering for butikker som selger fra Portugal til andre EU-land: IVA krevd inn ved salg over terskelen, riktig sats per destinasjonsland, og logikk rundt registreringskravet
• Frakt med CTT, DPD og MRW: fraktsoner, prisregler basert på vekt og volum, pakkeboks som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• Aldersverifisering og fraktrestriksjoner for vinbutikker: bekreftelse ved checkout, blokkering av levering til land der alkoholfrakt er forbudt, og tydelig merking av produkter med opprinnelsesbetegnelse (DOC Douro, Vinho Verde)
• Angrerett bygget inn i flyten: retur- og angreskjema, riktig informasjon i ordrebekreftelse og e-post, slik at den lovpålagte 14-dagersfristen ikke blir en manuell jobb for kundeservice
• Flerspråklig butikk for turisthandlere: portugisisk, engelsk, spansk og fransk med riktig hreflang, oversatt kasse og produktmetadata for sesongbasert turisttrafikk
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller integrasjon mot booking- og opplevelsessystemer, med autentisering og idempotente betalingsstier

#Hvorfor portugisiske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Porto er det ikke produktkatalogen som er vanskelig, det er kassen. MB WAY oppfører seg ikke som et vanlig kortgateway: kunden bekrefter i mobilbanken, betalingen skjer asynkront, 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 MB WAY-betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Multibanco er den andre spesialiteten. Kunden får en ni-sifret entidade og referanse, betaler i minibanken eller nettbanken, og bekreftelsen kan komme timer senere. Butikken må holde ordren som «venter betaling» til gatewayen rapporterer inn, og lageret må ikke plukke varen før pengene er der. Uten den logikken sender vinprodusenter flasker til ordrer som aldri ble betalt.

Frakt er den tredje fellen. En portugisisk kunde forventer CTT som standardleverandør, med sporing kunden ser i e-posten. For vinbutikker kommer glassvekt, emballasjekrav og leveringsrestriksjoner oppå det vanlige fraktoppsettet. Vi setter opp fraktsonene og leveringsvalgene som hører til det portugisiske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Porto

Porto er Portugals andre økonomiske senter og inngangsporten til Douro. Ribeira, Gaia og vinlagrene langs elven driver turismehandel som topper seg om sommeren og i høstsesongen under vindyrkingen. UPTEC og Universidade do Porto har gjort byen til et teknologimiljø der netthandlere, vingårder og opplevelsesleverandører møtes. WordPress Porto Meetup er det lokale miljøet der utviklere deler erfaringer med WooCommerce og WordPress.

Kundene våre i Porto spenner fra vingårder som selger DOC Douro og portvin direkte til forbruker i Portugal og EU, til turisthandlere som selger lokalproduserte varer og opplevelser til besøkende fra hele verden. Fellesnevneren er at de trenger en butikk som tar MB WAY på alvor, regner IVA riktig, håndterer sesongtopper uten at kassen kollapser, 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 turistsesongen treffer, 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.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Multibanco, MB WAY, kort), fraktsoner mot CTT og DPD, IVA-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 pakkebokslogikk, IVA- og OSS-håndtering, aldersverifisering for alkoholprodukter, 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-MB WAY på hver gateway, Multibanco-referansebetaling, refusjon og delvis refusjon, retur etter angrerett, 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 Porto-butikker

• MB WAY mangler eller er feilkoblet. En vinbutikk markerte ordrer betalt på redirect i stedet for på webhook fra Easypay. 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 i turistsesongen. En Ribeira-handlende med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før MB WAY-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.
• IVA og OSS regnet feil. En butikk som solgte vin både innenlands i Portugal og til Frankrike og Tyskland blandet sammen portugisisk IVA og OSS-reglene. Vi skilte de to flytene, satte riktig sats per produktgruppe og destinasjonsland, og fikk grenseoverskridende salg merket riktig mot rapporteringskravene.
• Multibanco-ordre plukket for tidlig. En produsent sendte vinflasker samme dag som referansen ble generert, før betalingen var bekreftet. Vi satte ordrestatus til «venter betaling» til gatewayen rapporterte inn, og la inn en admin-varsel når Multibanco-betalingen kom timer senere.

#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 Multibanco, MB WAY og kort avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager, regnskap 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 på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det portugisiske kunder forventer fra CTT, IVA og angrerett 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. 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 «Aceitar tudo»-knapp uten avvisning. Personvernerklæringen må nevne databehandlere (Easypay, EuPago, CTT) og formålet med hver behandling. Dette er ikke juridisk rådgivning, men teknisk implementering av det regelverket krever.

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

For vinbutikker og turisthandlere i Porto betyr sesongtopper at ytelsen må holde når trafikken tredobles i juli og august. Vi tester kassen under simulert belastning før høysesongen, ikke etter at kundene allerede har opplevd treg checkout.

#Spørsmål Porto-butikker stiller oss

Setter dere opp MB WAY i kassen? Ja. Vi integrerer MB WAY via Easypay, EuPago eller tilsvarende, med app-flyt på mobil, 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, viser priser inkludert IVA slik portugisiske forbrukere forventer, og skiller OSS-flyten for salg til andre EU-land fra ordinær innenlands IVA.

Hvilke fraktløsninger støtter dere? CTT, DPD og MRW, med fraktsoner, prisregler etter vekt og volum, pakkeboks som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen. For vinbutikker legger vi til aldersverifisering og leveringsrestriksjoner per destinasjonsland.

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 Porto? Ja. Vi har tyngdepunktet i Porto- og Douro-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 inkludert pakkebokser, regnskap i Moloni, InvoiceXpress eller Primavera, 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 Easypay, EuPago eller tilsvarende MB WAY-endepunkt. 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 er en referansebetaling med forsinkelse. Kunden får entidade og referanse, betaler i minibanken, og bekreftelsen kan komme timer senere. Ordren må holde status «venter betaling» til gatewayen rapporterer inn. Lageret plukker ikke varen før betalingen er bekreftet. For vinbutikker er dette kritisk: flasker sendes ikke på et løfte.

Kort går ved siden av, ikke i stedet for. Stripe eller en portugisisk acquirer dekker kunder som ikke bruker MB WAY eller Multibanco, alltid med 3D Secure. Tre gatewayer betyr tre sett med statuskoder, tre refusjonsmodeller og tre 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, DPD og MRW

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

Pakkeboks er et eget datafelt. Kunden velger et konkret CTT-utleveringssted i kassen, og valget må lagres på ordren som en identifikator fra CTT, 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.

Vin krever ekstra validering. Aldersverifisering ved checkout, emballasjekrav for glass, og blokkering av levering til land der alkoholfrakt er forbudt. Disse reglene settes som produktkategoriregler og checkout-validering, ikke som manuelle notater i ordren.

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 turister som bestiller fra utlandet og venter på Douro-vin.

#Regnskap: Moloni, InvoiceXpress eller Primavera

Salget bokføres én gang, med riktig IVA-kode. Moloni, InvoiceXpress og Primavera har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig IVA-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. Easypay og EuPago 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 Portugal, skal fakturaen sendes via det portugisiske e-fakturasystemet, med NIF-nummer på mottakeren. Det er en egen flyt i kassen: felt for NIF, validering, og et annet dokumentløp enn forbrukersalget.

Oppbevaringsplikt og SAF-T (PT). Bokføringspliktig dokumentasjon skal oppbevares i henhold til portugisisk regelverk, og regnskapssystemet må kunne levere SAF-T (PT) på forespørsel fra skattemyndighetene. I praksis betyr det at butikken ikke er regnskapssystemet: WooCommerce er kilden, Moloni eller InvoiceXpress 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 Porto, 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 Easypay eller EuPago 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. 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 regnskaps-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 Porto, gjelder de samme portugisiske kravene til MB WAY, IVA og CTT-frakt, men med lokal logistikk og kundemønster. Se WooCommerce-utvikler i Lisboa for hvordan oppsettet tilpasses hovedstaden, og WooCommerce-utvikler i Madrid for det iberiske markedet.

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

#Andre europeiske byer

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

• Stockholm - WooCommerce-utvikler i Stockholm
• Göteborg - WooCommerce-utvikler i Göteborg
• København - WooCommerce-utvikler i København
• Helsinki - WooCommerce-utvikler i Helsinki

#Start et WooCommerce-prosjekt i Porto

Trenger butikken din i Porto en kasse som tar MB WAY på alvor, regner IVA 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 en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon for WordPress.