Talen
2+
Nederlands en Engels volledig server-side gerenderd — elke URL, meta-tag en productbeschrijving meertalig en SEO-geoptimaliseerd.
Een internationaal schaalbaar e-commerce platform is een webshop die van dag één meertalig, PSD2-compliant en architectureel uitbreidbaar is — zonder dat een nieuwe markt een herschrijving vereist. Wij bouwden zo'n platform voor een high-end kledingmerk uit de Benelux dat zijn collecties als kunst presenteert. Het draait op Next.js 15 App Router met server-side i18n via next-intl, beheert complexe productstructuren met meerdere varianten via Prisma en PostgreSQL, en verwerkt betalingen via Mollie — inclusief iDEAL, Bancontact en creditcard.
Betaalmethoden
3
iDEAL, Bancontact en creditcard via Mollie — PSD2-compliant en klaar voor uitbreiding naar extra markten.
Dubbele verkopen
Onmogelijk
Voorraad per variant is beveiligd tegen gelijktijdige bestellingen — ook bij een product launch of flash sale.
Van probleem naar architectuur
Uitdaging
Mode als kunst. Internationale ambities.
Een high-end kledingmerk dat zijn collecties als kunst presenteert, met klanten in Nederland, België en daarbuiten, had nood aan een platform dat hun internationale positionering waarmaakte: meertalig, SEO-proof, snel en veilig. Bestaande oplossingen konden de complexe productstructuren — kledingstukken in meerdere maten en kleuren, met unieke productafbeeldingen en individuele aantallen per variant — niet correct modelleren.
Bovendien vereiste de Europese PSD2-richtlijn een compliant betaalflow, waarbij sterke klantauthenticatie (SCA) correct verwerkt wordt — iets wat een eigengebouwde integratie bijna onmogelijk correct implementeert zonder een gecertifieerde betaalprovider.
Context
High-end kledingstukken, beperkte collecties, internationale klanten, hoge privacygevoeligheid en piekbelasting bij product drops.
Analyse
Zes structurele beperkingen
Meertalige SEO was onmogelijk met de bestaande oplossing: URL-structuur, meta-tags en content werden niet per taal gesplitst.
Complexe productstructuren (meerdere varianten per kledingstuk — maat, kleur, uitvoering — met unieke productafbeeldingen en voorraad per variant) pasten niet in standaard e-commerceplatformen.
Bij productlanceringen met hoge gelijktijdigheid konden klanten hetzelfde schaarse exemplaar dubbel kopen.
De betaalintegratie was niet PSD2-compliant en ondersteunde geen Belgische en Nederlandse betaalmethoden zoals Bancontact en iDEAL.
Cart state verdween bij sessie-einde — klanten verloren hun winkelmandje tussen apparaten en sessies.
Geen adminpanel: producten, voorraad en orders werden handmatig beheerd via de database.
Aanpak
Vijf pijlers van internationalisatie tot betaling
De architectuur is opgebouwd als vijf onafhankelijke maar naadloos samenspelende lagen: van meertalige routing over een robuust productmodel tot een veilige betaalflow en een schaalbare database-infrastructuur.
01
Meertalige routing met next-intl
Alle routes opgebouwd onder een [locale]-segment. Middleware detecteert voorkeurstaal en redirect. Vertalingen server-side geladen zodat SEO en performance optimaal blijven.
02
Productmodel met varianten & adminpanel
Prisma-schema met producten, varianten, afbeeldingen per variant en transactioneel voorraadbeheer. Het adminpanel biedt schermen voor productbeheer (aanmaken, bewerken, archiveren), voorraadmutaties per variant, orderoverzicht met statusfilter en een preview-modus voor publicatie. Validatie en foutafhandeling zijn ingebouwd op zowel client- als serverniveau.
03
Mollie checkout via server actions
Bestelling aanmaken → Mollie payment creëren → redirect → webhook voor statusupdate. Orders pas definitief na betaling, met rollback bij mislukking.
04
Schaalbare backend & security
Neon PostgreSQL met connection pooling voor serverless. Rate limiting op gevoelige endpoints. NextAuth v5 met role-based access control voor adminroutes.
05
Cart & wishlist synchronisatie
Zustand voor optimistische client-state, gesynchroniseerd naar PostgreSQL bij elke wijziging. Anonieme sessies worden na login automatisch samengevoegd.
Betalingsarchitectuur
Mollie checkout: veilig, compliant en schaalbaar
Betaalintegraties zijn een van de meest foutgevoelige onderdelen van een e-commerce platform. Verkeerd geïmplementeerd leiden ze tot onterechte orderbevestigingen, voorraaddiscrepanties of beveiligingslekken. Onze aanpak delegeert de volledige betaalcomplexiteit — inclusief SCA en PSD2 — aan Mollie en behoudt volledige controle over het order- en voorraadmodel via server actions.
1
Order aanmaken
Server action maakt order aan en reserveert voorraad in één Prisma-transactie. Status: pending.
2
Mollie payment
Mollie payment-object gecreëerd via de API. Klant wordt geredirect naar Mollie's hosted payment page.
3
Betaling verwerkt
Klant betaalt via iDEAL, Bancontact of creditcard. Mollie verwerkt SCA en stuurt een webhook.
4
Webhook & bevestiging
Beveiligd webhook endpoint verifieert status bij Mollie, bevestigt of annuleert de order en geeft vrijgegeven voorraad terug.
Technische architectuur
Technische kern
Vier sleuteltechnologieën
Next.js 15 App Router + next-intl
[locale]-segment in de routestructuur geeft elke taal een eigen URL-hiërarchie. next-intl laadt vertalingen server-side zodat Google elke taalvariant volledig gecrawled kan indexeren.
next-intl App Router documentatie →Prisma ORM + Neon PostgreSQL
Productmodel met varianten, voorraad per variant en transactionele mutaties. Neon's ingebouwde pgBouncer-pooler absorbeert piekbelasting zonder databaseconnectiefouten in serverless omgevingen.
Neon connection pooling →Mollie Payments API
Checkout via server actions: order aanmaken, payment creëren, redirect naar Mollie, webhook voor statusupdate. Beveiligd endpoint met origin check en secret-verificatie.
Mollie Orders API documentatie →NextAuth v5 + Prisma Adapter
JWT-sessies met role-based access control. Middleware bewaakt alle adminroutes. Rate limiting via in-memory sliding window op login en betalingsgerelateerde endpoints.
Vergelijking
Voor vs. na het platform
Meertalige SEO
Voor
Één URL, geen hreflang, geen server-side vertalingen
Na
Aparte URL per taal, hreflang, server-side meta-content
Variantbeheer
Voor
Geen varianten of handmatig in beschrijving
Na
Eigen voorraad, prijs en afbeeldingen per variant
Dubbele verkopen
Voor
Mogelijk bij gelijktijdige aankopen
Na
Architectureel onmogelijk via Prisma-transacties
Betaalmethoden
Voor
Geen iDEAL of Bancontact, niet PSD2-compliant
Na
iDEAL, Bancontact, creditcard via Mollie
Cart persistentie
Voor
Verloren bij sessie-einde of ander apparaat
Na
Gesynchroniseerd naar DB, beschikbaar na inloggen
Beheer
Voor
Direct in de database of via externe tool
Na
Custom adminpanel met preview en validatie
Resultaat
Resultaat
Zes meetbare verbeteringen
Direct meertalig en SEO-proof gelanceerd: afzonderlijke URL-structuren per taal, hreflang-tags en server-side vertaalde meta-content.
Nul dubbele verkopen geregistreerd, ook bij gesimuleerde flash sales met honderden gelijktijdige verzoeken per variant.
Klanten betalen via iDEAL, Bancontact of creditcard — conversie in de Benelux sterk verbeterd door lokale betaalmethoden.
Cart en wishlist beschikbaar op elk apparaat na inloggen — geen verloren sessies meer.
Volledige beheerderscontrole over producten, varianten, voorraad en orders via een gebruiksvriendelijk adminpanel.
Schaalbaar naar extra markten en talen zonder refactor van de kernarchitectuur.
Architectuurprincipe
Schaalbaar door ontwerp, niet door toeval
Een platform dat vandaag werkt voor de Benelux maar morgen uitgebreid moet worden naar Duitsland of het Verenigd Koninkrijk, mag geen architecturele herschrijving vereisen. Door de locale-segmentstructuur en de modulaire vertaallaag te ontwerpen vooraleer de eerste pagina gebouwd was, is een extra taal of markt toevoegen een configuratievraag, geen refactorvraag.
Hetzelfde geldt voor Mollie: door de checkout volledig server-side te bouwen via server actions en webhooks, is het toevoegen van een extra betaalmethode of markt een API-configuratie, geen codeherschrijving.
Principe
Uitbreidbaarheid begint bij de initiële architectuurkeuze — niet bij een refactor achteraf.
Security & compliance
PSD2, AVG en security by design
Betaalverkeer, privacywetgeving en webbeveiliging zijn geen afterthought — ze zijn ingebakken in de keuze voor Mollie als gecertifieerde betaalprovider, de AVG-conforme dataopslag en de beveiligde routinglaag conform de vereisten van de Gegevensbeschermingsautoriteit.
PSD2 / SCA
Mollie verwerkt alle Strong Customer Authentication vereisten conform de Europese betaalrichtlijn — geen eigengebouwde 3DS-implementatie vereist.
Rate limiting
Sliding window rate limiting op login en betalingsgerelateerde endpoints voorkomt brute-force- en credential stuffing-aanvallen.
RBAC via NextAuth v5
Rolgebaseerde toegangscontrole bewaakt alle adminroutes via middleware. JWT-sessies verlopen automatisch en worden niet hergebruikt.
Takeaway
Internationaal schalen begint bij de routingstructuur — niet bij een vertaalplugin die achteraf wordt toegevoegd.
Wie later internationaal wil, maar zijn platform lokaal bouwt, betaalt de prijs bij elke uitbreiding. Wie de locale-structuur van dag één inbouwt, heeft een platform dat groeit zonder te breken.
Veelgestelde vragen over internationaal e-commerce met Next.js en Mollie
Waarom Next.js App Router voor een internationale webshop?
De App Router van Next.js 15 laat toe om routes te organiseren onder een [locale]-segment, zodat elke pagina een taalprefix krijgt (bv. /nl/shop of /en/shop). Server components zorgen voor snelle first-load prestaties, terwijl de middleware automatisch de voorkeurstaal detecteert en de gebruiker doorstuurt. Dat is fundamenteel anders dan client-side i18n waarbij de browser eerst JavaScript laadt vooraleer de vertaalde content beschikbaar is — een nadeel voor zowel SEO als gebruikerservaring.
Hoe werkt de Mollie betalingsflow technisch?
De checkout verloopt volledig via server actions. Bij het plaatsen van een bestelling worden drie stappen atomair uitgevoerd: voorraad reserveren, een order aanmaken in de database en een Mollie payment-object creëren via de Mollie API. De klant wordt vervolgens doorgestuurd naar Mollie. Na betaling stuurt Mollie een webhook naar ons beveiligd endpoint. Dat endpoint verifieert de herkomst via een gedeeld secret, haalt de betalingsstatus op bij Mollie en bevestigt of annuleert de order. Orders die na een bepaalde tijd onbetaald blijven worden automatisch geannuleerd en de voorraad vrijgegeven.
Hoe wordt voorraad per variant beheerd bij gelijktijdige aankopen?
Elke productvariant heeft een eigen voorraadteller in de database. Bij een aankoop wordt de voorraad verlaagd via een Prisma-transactie die de controle (is er nog voorraad?) en de schrijfoperatie (verlaag de teller) combineert als één atomaire eenheid. Zelfs bij honderden gelijktijdige aankopen — zoals bij een product drop — kan een variant nooit negatieve voorraad bereiken. Prisma's optimistic concurrency of database-level locking garandeert dit op infrastructuurniveau.
Wat is Neon en waarom is het geschikt voor serverless e-commerce?
Neon is een serverless PostgreSQL-provider met ingebouwde connection pooling via pgBouncer. Bij een klassieke PostgreSQL-setup kan elke serverless functie-instantie een nieuwe databaseverbinding openen, waardoor het maximale aantal verbindingen snel bereikt wordt bij piekbelasting. Neon's pooler hergebruikt verbindingen transparant, zodat het platform duizenden gelijktijdige serverless-aanroepen kan verwerken zonder databaseconnectiefouten. Dat maakt het ideaal voor Next.js-applicaties op Vercel of vergelijkbare platforms.
Hoe wordt de winkelwagen gesynchroniseerd tussen apparaten?
De cart state wordt dubbel opgeslagen: Zustand beheert de lokale, optimistische staat in de browser voor een snelle gebruikerservaring zonder netwerklatentie. Bij elke aanpassing wordt de staat asynchroon gesynchroniseerd naar de PostgreSQL-database via een server action. Wanneer een ingelogde gebruiker op een ander apparaat verder winkelt, laadt de server action de cartinhoud op uit de database en hydrateert Zustand. Gasten krijgen een anonieme sessie-ID die na login automatisch aan het gebruikersaccount gekoppeld wordt.
Hoe worden adminroutes beveiligd in dit platform?
Authenticatie verloopt via NextAuth v5 met een credentials provider en Prisma adapter. Elke gebruiker heeft een rol (admin, medewerker, klant) opgeslagen in de database. De Next.js middleware controleert bij elke request naar een admin-route of er een geldige JWT-sessie aanwezig is met de juiste rol. Zonder geldige sessie wordt de gebruiker omgeleid naar de loginpagina. Gevoelige endpoints zoals voorraadbeheer en orderverwerking zijn bovendien beveiligd met rate limiting om brute-force-aanvallen te voorkomen.
Is dit platform ook inzetbaar voor andere kledingmerken of modebedrijven?
Absoluut. De architectuur — meertalige routing, transactioneel voorraadbeheer per variant, Mollie-checkout en een schaalbare serverless backend — is universeel inzetbaar voor elk premium kledingmerk of modebedrijf dat internationaal actief is: van limited-edition streetwear tot seizoenscollecties en haute couture. De modulaire opbouw maakt het relatief eenvoudig om nieuwe markten of betaalmethoden toe te voegen. We hebben het bewust zo ontworpen dat uitbreiding naar extra locales of betaalproviders geen refactor van de kernarchitectuur vereist.
Hoe lang duurt het bouwen van zo'n e-commerce platform en wat kost het?
De doorlooptijd voor een platform van dit niveau — meertalig, met variantbeheer, Mollie-integratie en een adminpanel — ligt doorgaans tussen de 8 en 16 weken, afhankelijk van de complexiteit van het productcataloog en de gewenste maatwerk-UX. We werken iteratief: een eerste versie met de kernfunctionaliteit (shop, checkout, adminpanel) is sneller live dan een volledig uitgewerkt platform. Kostprijs hangt af van scope en looptijd — we maken altijd eerst een gedetailleerde analyse op maat. Neem contact op via de contactpagina voor een vrijblijvende inschatting.
Hoe wordt het platform onderhouden en uitgebreid na de oplevering?
We leveren platforms op met volledige documentatie en broncode. Na oplevering bieden we onderhoudscontracten aan waarbij we dependency-updates, beveiligingspatches en kleine aanpassingen verzorgen. Uitbreidingen — nieuwe betaalmethoden, extra talen, bijkomende productcategorieën of koppeling met een ERP of boekhoudpakket — worden als aparte opdrachten gepland. Omdat de architectuur modulair is opgebouwd, zijn uitbreidingen gericht en goedkoper dan bij een monolithisch platform. De klant blijft altijd eigenaar van de code en de data.
