Een wachtkamer voor WooCommerce die je eigen winkel handhaaft

De plugin draait in je winkel, niet ervoor

De gebruikelijke WooCommerce-wachtkamer vraagt je om de leverancier in het verzoekpad te zetten — een DNS-wijziging, een reverse proxy, of een CDN-functie die onderschept voordat WordPress wordt bereikt. Vanaf dat moment hangt je winkel af van hun infrastructuur.

Deze draait het om. De wachtrij zelf, het uitgeven van toegangsbewijzen en de botscoring draaien in onze cloud. De plugin draait in de jouwe en doet het handhaven: komt een shopper binnen met een ondertekend toegangsbewijs, dan controleert de plugin de handtekening lokaal, zonder netwerkaanroep, en laat hem door. De grens tussen ons wordt één keer gepasseerd, bij het uitgeven van een bewijs — nooit bij het laden van een pagina.

Wat dat je oplevert:

• Geen DNS-wijziging en geen reverse proxy. Je origin verhuist niet.
• Geen aanroep per verzoek. De controle is een lokale HMAC-check, dus er komt geen extra rondje bij een paginalading en je bent niet afhankelijk van onze latency.
• Geen van je verkeer loopt via ons. De betaalgegevens van je klanten raken onze systemen nooit.

Schaduwmodus is de standaard, en dat is het punt

Activeer de plugin en hij handhaaft niets. Hij logt wat hij zou hebben gedaan — welke verzoeken hij zou hebben afgeschermd, welke bewijzen hij zou hebben geweigerd — en laat elke shopper gewoon door. Je leest het log, bepaalt of hij zich gedraagt zoals je verwacht bij jouw thema, jouw caching en jouw checkout, en pas dan zet je hem aan.

We beginnen hiermee omdat “we hebben nog nooit van jullie gehoord” een terecht bezwaar is tegen het plaatsen van iets vóór een checkout. Het antwoord is geen muur met logo’s. Het antwoord is dat je dit kunt installeren, er een week naar kunt kijken, de broncode kunt lezen, en niets hebt geriskeerd.

Hij valt open, en dat is een ontwerpkeuze

Zijn wij onbereikbaar, dan blijft de plugin verkopen. Hij houdt een duurzaam laatst-bekend-goed beleid vast, zodat het afschermen doorloopt terwijl wij plat liggen, in plaats van om te vallen naar “blokkeer iedereen” of “scherm niets af”. De beschikbaarheid van jouw winkel hangt niet af van de onze.

Handhaving op bestelniveau, niet alleen op paginaniveau

De pagina afschermen waarop een shopper landt is de makkelijke helft. De helft die een gelimiteerde oplage echt beschermt, is voorkomen dat één toelating vijf bestellingen wordt.

Elk toegangsbewijs is ondertekend en eenmalig. De plugin dwingt dat af bij de checkout, dus een bewijs dat al is gebruikt kan niet worden hergebruikt, doorgestuurd naar een vriend, of door een script uitgewaaierd over parallelle sessies na één rechtmatige toelating. Niemand anders in deze categorie levert dat als onderdeel van een volwaardig WooCommerce-product.

Waar de plugin alleen niet genoeg is — en dat zeggen we vóór je koopt

De plugin draait binnen PHP. Beantwoordt iets vóór PHP het verzoek, dan wordt de plugin nooit uitgevoerd. Dat is geen bug en het is niet op te lossen binnen WordPress:

• Volledige paginacaching die PHP overslaat — LiteSpeed cache, nginx-microcaching, Varnish, of een CDN dat je HTML cachet — serveert een gecachete pagina aan een wachtende shopper. De cache-onderdrukking van de plugin kan geen cache voor zijn die antwoordt zonder PHP aan te roepen.
• Headless winkels en Store-API-gedreven front-ends. Daar schermt de plugin het leespad helemaal niet af.

Voor beide heb je ook de edge-connector nodig — een Cloudflare Worker die vóór de cache afschermt, met de plugin die er achter nog steeds op bestelniveau handhaaft. De edge voorkomt dat je winkel wordt platgelopen; de plugin voorkomt dat één toelating vijf bestellingen wordt. Beide draaien is de sterkste opstelling, en het is een eerlijke architectuureis, geen upsell.

Op standaard WooCommerce-hosting met paginacaching uit voor ingelogde en winkelwagensessies schermt de plugin alleen elke paginalading en elke bestelling af. Twee grenzen blijven ook dan staan, en die zijn de eerlijke reden om de connector toe te voegen, geen verkoopreden: de WordPress REST-catalogus (/wp-json) wordt bij de origin nooit afgeschermd voor browsen, omdat de hook waarop de plugin afschermt daar niet afgaat — een wachtende bezoeker kan dus nog steeds productgegevens lezen; en elke wachtende shopper die zijn beurt komt peilen kost een volledige WordPress- en WooCommerce-opstart, dus de winkel moet de menigte nog steeds overleven, ook al is de toewijzing eerlijk. Met de connector ervoor komt de menigte nooit aan.

Hoe je veilig live gaat

1. Upload de plugin en activeer hem. Hij staat in schaduwmodus: hij logt wat hij gedaan zou hebben en handhaaft niets.
2. Plak je installatiecode — één string uit de console. Geen DNS, geen proxy, geen wijziging aan je origin.
3. Kijk mee in het log tijdens een gewone handelsdag, en daarna tijdens een kleine drop.
4. Zet handhaving aan als je tevreden bent. Stel je toelatingstempo in — geen ondergrens en geen limiet, bij elk pakket.

Zijn wij daarna op enig moment onbereikbaar, dan houdt de plugin het laatst opgehaalde beleid vast en blijft daarop verkopen. Live gaan is een schakelaar die je omzet, geen overstap.

Het geheel is MIT-gelicentieerd, dus je kunt precies lezen wat het doet vóór stap één.

Wat hij niet doet

Geen voorrangs- of uitnodigingscodes — de vraag die we het vaakst krijgen, en hij is er niet. Shoppers zien altijd hun positie; twee optionele extra’s per winkel staan uit tot jij ze aanzet — een geschatte wachttijd in het huidige tempo (verborgen zolang de rij gepauzeerd is) en een aftelklok naar een ingeplande presale-trekking. Geen publieke API, SDK of webhooks. Meerdere winkels worden vandaag per winkel gefactureerd, wat goed is om te weten als je er meerdere draait.