Webshops in Umbraco: packages, maatwerk en koppelingen met PIM, Exact Online en Shopify
Van standaardpackage tot een volledig eigen shopping framework. En alles wat erbij hoort: productdata uit een PIM binnenhalen, orders en facturen door laten stromen naar Exact Online, en Shopify als kassa koppelen aan een rijke Umbraco-frontend.
Het korte antwoord
Een webshop bouwen op Umbraco kan ruwweg op drie manieren, en welke je kiest hangt af van wat je eigenlijk verkoopt en hoe complex de rest van je organisatie is. Een package zoals uCommerce of Vendr als het vooral snel en standaard moet. Een eigen shopping framework als je producten, prijslogica of orderstroom niet in een standaard doosje passen. Of een combinatie met Shopify, waarbij de content in Umbraco blijft en Shopify alleen het kassawerk doet.
Het overgrote deel van wat wij de afgelopen jaren hebben opgeleverd zit in die tweede en derde categorie. Niet omdat packages slecht zijn, maar omdat webshops zelden echt standaard blijven zodra je een koppeling met een PIM, een ERP of een boekhoudpakket als Exact Online erbij zet. Die integraties bepalen vaak meer over een project dan de winkelwagen zelf.
Packages voor standaard shops
Het Umbraco-ecosysteem heeft een paar volwassen e-commerce packages. uCommerce en Vendr (de opvolger van Tea Commerce) zijn de twee die je in de praktijk het vaakst tegenkomt. Beide draaien native op Umbraco, hebben een redelijke backoffice-ervaring en leveren alles wat een standaard webshop nodig heeft: catalogus, winkelwagen, checkout, koppeling met betaalproviders en een basis-orderbeheer.
Vendr is de modernere keus. Het package is gebouwd met Umbraco's manier van werken in gedachten, is relatief licht en speelt prettig samen met BlockGrid-content. uCommerce heeft meer functies out-of-the-box, maar is historisch zwaarder en vraagt meer setup-werk. Voor een eenvoudige B2C-shop met een paar honderd producten en een standaard orderflow: perfect. Je bent in enkele weken live.
Waar packages beginnen te knellen is op het moment dat een klant zegt: “Ja maar onze producten hebben zes varianten, en alleen klanten uit Duitsland zien de btw-prijs, en we willen per klantgroep een ander tarief, en de voorraad staat trouwens in SAP.” Dan begin je overrides te schrijven op overrides, en verlies je langzaam het voordeel waarom je in eerste instantie voor een package had gekozen.
Vier routes voor Umbraco-commerce
Ons eigen shopping framework
Voor shops op maat gebruiken we een intern opgebouwd shopping framework. Het is geen vervanger van Umbraco, maar een set herbruikbare componenten die we over de jaren hebben gedestilleerd uit shops die we gebouwd hebben. Het idee is simpel: alles wat elke shop toch opnieuw nodig heeft, hebben we één keer goed geschreven; alles wat per klant anders is, blijft per klant aanpasbaar.
Wat erin zit: een catalogusmodel dat varianten, bundels en configureerbare producten aankan; een winkelwagen die in sessie of in database kan draaien; een orderstroom met statussen, events en hooks waar eigen logica in hangt; koppelingen met Mollie, Stripe en Adyen; btw-logica per land en klantgroep; en een account-sectie waar klanten hun bestellingen, downloads en facturen terugvinden.
Het verschil met een package: alles is gewoon Razor, C# en Umbraco. Geen vreemde backoffice-secties, geen eigen database-schema dat niet naar uSync te krijgen is, geen afhankelijkheid van een leverancier die morgen kan besluiten een andere koers te varen. Als er iets afwijkends moet gebeuren, bijvoorbeeld een prijsberekening op basis van volume, een product dat pas zichtbaar wordt na inloggen, of een abonnementsmodel in plaats van losse aankoop, dan schrijven we dat stuk zelf en laten we de rest staan.
Voor welk type klant werkt dit goed? Vooral voor B2B-shops, voor winkels met ingewikkelde productstructuren, en voor organisaties die de webshop beschouwen als onderdeel van een bredere digitale keten in plaats van een losstaand verkoopkanaal.
Productdata uit een PIM
Zodra een catalogus voorbij een paar honderd producten groeit, wil niemand meer producten in de webshop zelf onderhouden. Dan zit de bron van de waarheid in een PIM: Akeneo, Contentserv, Plytix, Perfion of een zelfgebouwd productregistratiesysteem. De webshop is vanaf dat moment alleen nog een consument van die data.
De koppeling met een PIM leggen we zelden eenmalig. Wat er wel gebeurt: we bouwen een synchronisatieproces dat volgens een schema of op basis van webhook-events de wijzigingen binnenhaalt. Nieuwe producten, gewijzigde specificaties, aangepaste assets, afgekeurde artikelen. Alles stroomt via een importlaag die validatie, mapping en foutafhandeling doet voordat het in Umbraco landt.
Voorraden zijn een apart hoofdstuk. Die veranderen continu en moeten meestal bijna-live beschikbaar zijn, zeker als je risico loopt om iets te verkopen dat niet meer op voorraad ligt. Daarvoor bouwen we een apart, sneller kanaal: polling elke paar minuten of een webhook vanuit het ERP of de warehouse-software, met een cache-invalidatie-strategie die voorkomt dat stale voorraadstanden in de zoekresultaten blijven hangen. Afhankelijk van wat een klant nodig heeft, zetten we dat in Redis, in Umbraco's eigen cache of in een combinatie.
Wat in al die jaren steeds weer terugkomt: de koppeling zelf is vaak niet de moeilijkheid, de foutafhandeling wel. Wat doe je als een PIM-export half mislukt? Hoe weet je welke producten eigenlijk verwijderd zijn? Wat gebeurt er met URLs van producten die niet meer bestaan? Dat soort vragen beantwoorden we in de ontwerpfase, niet tijdens de eerste release.
Zo bouwen we een shop in vier fases
-
Welk systeem is de bron van wat — producten in de PIM of in Umbraco, klanten in Exact of in Umbraco, voorraad uit het ERP of WMS? Zonder deze afbakening krijg je synchronisatie-chaos waar dezelfde data op twee plekken afwijkt en niemand nog weet welke klopt.
-
Product-templates, variant-logica, winkelwagen en checkout-flow. Bij maatwerk: eigen shopping framework met cart in sessie of database. Bij Shopify-opzet: Shopify-cart direct in Umbraco-pagina's geïntegreerd via de Cart API.
-
PIM-synchronisatie (scheduled of webhook-based), ERP-orderflow (REST-API met OAuth en retry-logic), betaalprovider (Mollie, Stripe of Adyen). Foutafhandeling en idempotency staan bij elke integratie centraal.
-
Redactie-training, order-monitoring, foutmeldingen uit integraties live zien. Eerste twee weken hypercare. SEO-check op alle product- en categoriepagina's met structured data en redirects vanaf oude URLs.
Exact Online en CRM/ERP-koppelingen
Een webshop die geen signaal teruggeeft aan de boekhouding is onafgemaakt werk. Voor veel van onze klanten zit de financiële administratie in Exact Online. Soms in Moneybird, AFAS of SnelStart. Het principe is overal hetzelfde: de shop is de plek waar de klant bestelt, de CRM of het ERP is de plek waar het bedrijf de order verwerkt en factureert.
Een punt dat we klanten vooraf uitleggen: je hoeft niet alles te synchroniseren. Sterker nog, dat moet je meestal niet willen. Producten horen in de PIM. Klantgegevens kunnen prima primair in Exact staan, of juist in Umbraco, zolang één systeem maar de bron is. De koppeling hoeft maar één ding echt goed te doen: een order die in de webshop binnenkomt, netjes door laten stromen naar Exact, inclusief de juiste grootboekrekeningen, btw-codes en referentievelden.
Hoe we dat aanpakken verschilt per situatie:
- Orders doorzetten. Zodra een order is betaald en definitief, gaat hij als verkooporder of verkoopfactuur naar Exact. Via de REST-API van Exact Online, met OAuth-authenticatie en tokens die netjes worden ververst.
- Facturen terugkoppelen. Exact genereert de PDF-factuur, die halen we terug en hangen we aan de klant in Umbraco. De klant ziet in zijn account-sectie gewoon zijn facturen staan, zonder dat je daar een apart facturatiesysteem voor nodig hebt.
- Relaties aanmaken en matchen. Voor nieuwe kopers maken we automatisch een relatie aan in Exact, met correcte mapping naar bedrijf, debiteur en contactpersoon. Bestaande klanten worden gematcht op btw-nummer of e-mailadres, zodat je geen dubbele relaties opbouwt.
- Betaalstatussen synchroniseren. Een betaling die via Mollie binnenkomt, melden we terug aan Exact, zodat de openstaande post daar ook klopt.
Wat we bewust niet doen: een volledige “synchroniseer alles met alles” bouwen. Dat klinkt op papier mooi, maar in de praktijk krijg je er dubbele klantnummers, vertraagde updates en een koppeling die bij elke Exact-release weer stuk blijkt te gaan. Hoe beperkter de scope van de integratie, hoe betrouwbaarder het hele ding werkt.
Shopify als achterkant, Umbraco als voorkant
Een andere route die we de laatste jaren steeds vaker lopen: Shopify als kassa en voorraadmotor, Umbraco als content- en marketingplatform. Dat klinkt als het slechtste van twee werelden, maar in de praktijk is het vaak juist het beste. Shopify doet waar het goed in is, zoals checkout, betalingen, voorraad en fraudedetectie. Umbraco doet waar Shopify traditioneel zwak in is: meertaligheid, contentrijke pagina's, redactie-workflows en SEO-discipline.
Technisch lossen we dat zo op: via de Storefront API en Admin API van Shopify halen we producten, voorraad en prijzen binnen in Umbraco. De productpagina's worden aan de Umbraco-kant gerenderd, met volledige controle over templates, structured data, meertalige content en blocks rondom het product. Wanneer een klant afrekent, draagt Umbraco de winkelwagen over aan de Shopify-checkout, die vervolgens het financiële en logistieke deel afhandelt.
Wat er concreet aan componenten bij hoort:
- Een volledige Shopify-cart in de Umbraco-site. Bezoekers voegen vanuit Umbraco-pagina's producten toe aan hun Shopify-cart zonder dat ze doorhebben dat er twee systemen onder de motorkap werken. De cart wordt via de Shopify Cart API beheerd en blijft via een token gekoppeld aan dezelfde sessie, ook als iemand heen en weer klikt tussen pagina's.
- Tweezijdige synchronisatie. Shopify-producten en hun metadata worden in Umbraco gespiegeld, zodat redacteuren er content aan kunnen hangen: marketingtekst, blocks, video's, bijbehorende artikelen. Wijzigingen aan de Shopify-kant worden via webhooks naar Umbraco doorgeduwd.
- Meertaligheid op de content-laag. Shopify's taalondersteuning in de backoffice is beperkt. Umbraco eromheen geeft je alsnog een nette, per-taal bewerkbare productpagina, inclusief hreflang-structuur en taalspecifieke URL-aliases.
- Redirects en URL-structuur onder controle. Shopify's standaard URL-structuur is niet altijd ideaal voor SEO. In deze opzet bepaalt Umbraco de URLs en zorgt het ervoor dat oude paden netjes doorverwijzen naar de nieuwe.
Het voordeel voor klanten: je houdt Shopify als kassa (inclusief alle voordelen qua betaalgemak, Shop Pay en fraudeafhandeling) zonder dat je content-platform ervoor hoeft in te boeten. Veel D2C-merken die we kennen beginnen op een plain Shopify-thema en lopen daar vroeg of laat tegen de muur aan: te weinig SEO-ruimte, te weinig redactionele vrijheid, te weinig grip op meertaligheid. Dit is de route waarmee ze niet hoeven te migreren, maar hun verhaal wel goed kunnen blijven vertellen.
Welke opzet bij welk type shop?
Om het concreet te maken, zo adviseren we meestal:
- Standaard B2C-shop, tot een paar duizend producten, één of twee talen: een package zoals Vendr, eventueel met een lichte PIM-koppeling. Snel live, overzichtelijk te onderhouden.
- B2B-shop met complexe prijslogica, klantgroepen en ERP-integratie: ons eigen shopping framework, gecombineerd met een PIM-sync en een Exact Online (of vergelijkbare) koppeling voor orders en facturen.
- Merk met sterke content- en marketingbehoefte, internationaal: Shopify voor de commerce, Umbraco voor de content en SEO, aan elkaar geknoopt via de Shopify-API's.
- Hybride scenario: een deel van het assortiment in Umbraco (bijvoorbeeld digitale producten, licenties of abonnementen) en een deel in Shopify. Ook dat bouwen we als één samenhangende winkelervaring voor de klant.
Tot slot
De eerlijke samenvatting: er is geen one-size-fits-all voor webshops in Umbraco. Er zijn wel vier goed doordachte routes, en de juiste keuze begint bijna altijd bij de vraag waar de productdata vandaan komt en waar de order uiteindelijk verwerkt moet worden. Pas daarna gaat het over checkout-ervaring, templates en design.
Ben je aan het kiezen welke basis past bij jullie shop, of loop je vast in een integratie die al draait? Laat een korte omschrijving achter en we kijken samen naar wat voor jullie het meest logisch is. Geen verkooppraat, wel een developer die dit soort trajecten vaker heeft gezien.