Een webshop in verzorgingsproducten uit de omgeving van Breda draait het grootste deel van zijn omzet in de avonduren en het weekend. Op een zaterdag in het voorjaar viel iDEAL daar uit om 19:40. De eigenaar ontdekte het de volgende ochtend om half tien, toen hij op zijn telefoon keek en zag dat er sinds gisteravond niets meer was binnengekomen. Veertien uur, waarvan zeker zes drukke uren.

Deze case beschrijft precies wat er is gebeurd: hoe het probleem is opgespoord, wat de oorzaak bleek te zijn, wat de klap heeft gekost en welke drie maatregelen ervoor zorgen dat een volgende iDEAL-storing binnen een kwartier zichtbaar is. Het verhaal is bewust gedetailleerd, omdat de details hier het leerzame deel zijn.

De situatie: wat de klant zag

Bezoekers konden gewoon producten bekijken, in de winkelwagen leggen en naar de afrekenpagina. Daar stond iDEAL keurig in de lijst. Wie erop klikte en op “bestelling plaatsen” drukte, kwam niet bij zijn bank uit maar belandde terug op de winkelwagenpagina met een algemene melding dat er iets was misgegaan. Geen foutcode, geen uitleg.

Precies dat maakte het zo stil: de site was online, de uptimemelder had niets gemeld, en klanten die afhaakten belden niet. Ze gingen ergens anders kijken. Achteraf bleek dat er in die veertien uur zeven mensen wel het contactformulier hadden ingevuld, maar dat formulier ging naar een mailbox die alleen op werkdagen werd gelezen.

De omzetderving is later geschat op het niveau van een gemiddelde zaterdagavond plus zondagochtend. Wat er niet in zit, zijn de klanten die zijn weggegaan en niet zijn teruggekomen.

De aanpak: zoeken in de juiste volgorde

Zondagochtend is er in vaste volgorde gecontroleerd. Die volgorde is het meest overdraagbare deel van deze case.

  1. Is het een storing verderop in de keten? Eerst de statuspagina van de betaalprovider en de storingsmeldingen van de grote banken. Beide schoon. Daarmee viel de makkelijkste verklaring af.
  2. Doet het probleem zich bij alle banken voor? Een testbestelling met twee verschillende banken gaf hetzelfde resultaat. Dus niet bankspecifiek.
  3. Wat zegt het logbestand van de betaalplugin? Hier kwam de eerste harde informatie: een reeks meldingen dat het aanmaken van de betaling werd geweigerd wegens een authenticatiefout.
  4. Wat is er kort voor 19:40 veranderd? In het activiteitenlog van WordPress stond dat er die middag om 17:12 automatische updates waren uitgevoerd, waaronder een update van de betaalplugin.
  5. Doet de fout zich ook voor op een kopie van de site? Op de testomgeving met dezelfde plugin-versie: ja. Daarmee was het reproduceerbaar en dus oplosbaar.

Van melding tot oorzaak duurde dit ongeveer veertig minuten. Zonder het logbestand van de plugin was het waarschijnlijk een halve dag geworden.

De oorzaak: een combinatie van twee dingen

De update van de betaalplugin bevatte een wijziging in de manier waarop de API-sleutel wordt opgeslagen en gelezen. Bij deze installatie stond de sleutel niet in de plugin-instellingen maar was hij ooit via een constante in het configuratiebestand vastgelegd, door de bouwer van de shop, jaren eerder. De nieuwe versie las die constante niet meer op dezelfde manier uit, waardoor de plugin met een leeg veld naar de provider ging en een authenticatiefout terugkreeg.

Op zichzelf was de update niet fout. De afwijkende installatie was het probleem, in combinatie met automatische updates die op zaterdagmiddag hun gang gingen zonder dat er daarna iets werd getest.

Twee dingen kwamen dus samen, en dat is bij dit soort storingen bijna altijd zo. Een reguliere update is meestal veilig. Een reguliere update op een installatie met een oude bijzonderheid erin, zonder test achteraf, is dat niet. Meer over dit patroon staat in hoe u WooCommerce bijwerkt zonder de checkout te breken.

De oplossing

Het herstel zelf was klein. De API-sleutel is uit het configuratiebestand gehaald en op de reguliere plek in de plugin-instellingen gezet, waarna de betalingen direct weer werkten. Daarna is er een testbestelling van een euro gedaan, van klik tot bevestigingsmail, om zeker te weten dat de hele keten weer liep. Ook is gecontroleerd of de zeven bestellingen die tijdens de storing waren aangemaakt maar niet betaald, netjes waren geannuleerd; die klanten hebben persoonlijk een mail gekregen met een excuus en een betaallink.

Om 10:35 werkte de shop weer. Zondag was daarmee grotendeels gered; zaterdagavond niet.

Wat er daarna is veranderd

Drie maatregelen, alle drie binnen een week ingevoerd.

1. Automatische updates aangepast. WordPress-kernbeveiligingsupdates blijven automatisch. Updates van WooCommerce, van de betaalplugin en van het thema gaan niet meer vanzelf, maar worden op een vast moment op dinsdagochtend gedaan, eerst op een testomgeving, met daarna een testbestelling op de live-shop. Bewust op dinsdag, want dan is er de rest van de week ruimte om iets recht te zetten.

2. Monitoring op de bestelflow. Elk kwartier doorloopt een script de stappen tot en met de afrekenpagina en controleert of iDEAL zichtbaar is en of de betaling gestart kan worden. Daarnaast is er een melding als er tijdens openingsuren negentig minuten geen bestelling binnenkomt. Die tweede melding is de simpelste van de twee en zou deze storing binnen anderhalf uur zichtbaar hebben gemaakt in plaats van na veertien uur.

3. Weekendbereikbaarheid geregeld. Meldingen komen binnen op WhatsApp in plaats van in een mailbox, en er is vastgelegd wie er in het weekend kijkt en wat diegene wel en niet zelf mag doen. Ook is er een korte instructie gemaakt: hoe zet u iDEAL tijdelijk uit en bankoverschrijving aan, zodat er in elk geval nog besteld kan worden.

Die derde maatregel is misschien wel de belangrijkste. Techniek die niemand in de gaten houdt buiten kantooruren, helpt u in het weekend niet. Voor deze ondernemer was dat de reden om het onderhoud onder te brengen bij een partij die het structureel bewaakt; wij doen dat via WooCommerce-onderhoud door specialisten, maar het gaat vooral om het principe dat iemand verantwoordelijk is.

De les voor uw eigen shop

Vier punten om vanavond nog na te lopen:

  • Staat er ergens een instelling op een afwijkende plek? API-sleutels in configuratiebestanden, aanpassingen in een thema, eigen code van een vorige bouwer. Schrijf op wat u vindt. Onbekende afwijkingen worden storingen.
  • Wanneer draaien uw automatische updates? Vrijdagmiddag en zaterdag zijn slechte momenten, precies omdat er niemand achteraan kijkt.
  • Krijgt u een signaal als de omzet stilvalt? Een melding bij een uur zonder bestellingen is triviaal in te richten en vangt de meeste stille storingen.
  • Waar komen uw klantberichten binnen in het weekend? Uw contactformulier is soms uw beste storingsmelder, maar alleen als iemand het leest.

Tot slot

Een iDEAL-storing hoeft geen ramp te zijn. Wat deze zaterdag duur maakte, was niet de fout zelf maar de veertien uur waarin niemand het wist. Verkort die tijd, en u verkort de schade.

Concrete volgende stap: stel deze week een melding in die u waarschuwt als er tijdens uw drukste uren te lang geen bestelling binnenkomt, en spreek af wie daarop reageert in het weekend. Dat is een half uur werk en het is de goedkoopste verzekering die uw webshop kan hebben.