Cashless betalen op evenementen: hoe werkt het en wat bouw je zelf?.

Wat is cashless betalen op een evenement?

Wie weleens op een festival heeft gestaan kent het beeld: een polsbandje tegen een kastje, een piep, en je bier is betaald. Wat er onder die piep gebeurt is een van de eigenaardigste betaalsystemen die er bestaan. Er is geen bank bij betrokken op het moment van betalen, het netwerk mag wegvallen, er staan duizenden transacties per minuut tegenover een handjevol verkooppunten, en na afloop moet alles kloppen met een boekhouding die geen van de bezoekers ooit ziet.

In dit artikel leg ik uit welke modellen er zijn, waarom offline werken het uitgangspunt van het ontwerp hoort te zijn, wat er juridisch bij een eigen munteenheid komt kijken, en welke keuzes je maakt als je zo'n systeem laat bouwen in plaats van huurt.

Twee modellen: eigen munt of gewoon pinnen

De discussie begint bijna altijd verkeerd, met de vraag "gaan we cashless?" Dat is de verkeerde vraag, want er zijn twee fundamenteel verschillende manieren om hem te beantwoorden.

Bij een gesloten circuit geef je een eigen waarde uit: munten, credits, punten. Bezoekers wisselen euro's om en krijgen saldo dat alleen op jouw terrein geldig is. Bij een open circuit laat je bezoekers gewoon contactloos betalen met hun eigen bankpas of telefoon, en is er geen eigen waarde in omloop. Het verschil klinkt technisch maar raakt je hele exploitatie.

Meerdaagse evenementen met veel verkooppunten en wisselende barpartners kiezen bijna altijd voor een gesloten circuit. De snelheid aan de bar is daar het doorslaggevende argument: vijftienhonderd mensen die in twintig minuten pauze allemaal tegelijk willen afrekenen, is een doorstroomprobleem voordat het een betaalprobleem is. Eendaagse of kleinere evenementen zijn met contactloos pinnen vaak beter af — alle nazorg rond restsaldo valt dan weg.

Een eigen munteenheid is geen betaaltechniek maar een balanspost: je hebt geld ontvangen voor iets dat je nog moet leveren.

Waarom offline werken het uitgangspunt is

Op een leeg terrein werkt alles. Zodra er tienduizend telefoons staan die allemaal video uploaden, is mobiel netwerk een gok en is de tijdelijke wifi een enkelvoudig storingspunt met een generator eraan. Elk systeem dat per transactie een server nodig heeft, staat op het drukste moment stil. Daarom is dit het zeldzame geval waarin local-first geen voorkeur is maar een eis.

Waar staat de waarheid?

De kernvraag van elk ontwerp: waar leeft het saldo? Er zijn twee antwoorden, en ze hebben allebei een prijs.

• Saldo op de chip: het bandje draagt zijn eigen waarde. Het leesapparaat boekt af en heeft daar niemand voor nodig. Maximaal robuust, maar een kapot of verloren bandje betekent verloren saldo, en de chip moet goed beveiligd zijn — anders is hij te kopiëren of op te hogen.
• Saldo in het systeem: het bandje is alleen een identificatie, het saldo staat centraal en wordt naar de kassa's gekopieerd. Herstel na verlies is eenvoudig en fraude is lastiger, maar je moet accepteren dat twee kassa's tijdelijk een verschillend beeld van hetzelfde bandje hebben.

In de praktijk zie je meestal een combinatie: de chip draagt saldo voor snelheid en zekerheid, het centrale systeem houdt een grootboek bij dat na synchronisatie leidend is. Dat betekent dat je expliciet moet beslissen wat er gebeurt als die twee niet overeenkomen — en dat is een beleidskeuze, geen technische. Bij twijfel in het voordeel van de bezoeker beslissen kost je een klein bedrag aan vermeend saldo, maar bespaart een avond aan discussies bij de infobalie.

Elke transactie is een gebeurtenis, geen opdracht

Een kassa die offline afrekent, kan de uitkomst pas later melden. Bouw de terreintransactie daarom als een gebeurtenis met een eigen, op het apparaat gegenereerde identificatie en een tijdstempel. Bij synchronisatie stuurt het apparaat zijn hele reeks op; het centrale systeem verwerkt die idempotent, zodat een halve verbinding of een herstart nooit tot dubbele afboekingen leidt. Dat klinkt vanzelfsprekend, maar het is precies de plek waar zelfgebouwde systemen omvallen: de verbinding komt terug, het apparaat stuurt alles opnieuw, en de omzet verdubbelt in het dashboard.

Let ook op de klok. Apparaten die dagen op een terrein staan lopen uit elkaar, en als je de volgorde van transacties uit de tijdstempel afleidt, krijg je negatieve saldi die nooit zijn voorgekomen. Gebruik een teller per apparaat en behandel de tijd als informatie, niet als waarheid.

Terugbetalen achteraf: waar het echt spannend wordt

Het technische deel van cashless is te overzien. Het deel dat organisatoren bijt is wat er ná het evenement gebeurt met saldo dat niemand heeft uitgegeven.

Juridisch is de situatie eenvoudiger dan veel bezoekers denken: consumptiemunten en digitaal festivalsaldo zijn waardeproducten en geen wettig betaalmiddel, en een organisator is niet verplicht om ze terug te kopen. Wel gelden de gewone regels over duidelijke informatie: wat je belooft in je voorwaarden en aan de kassa, daar word je aan gehouden. En als je een termijn stelt waarna saldo vervalt, moet die vooraf kenbaar zijn — niet pas als iemand zich twee weken later meldt.

Dat maakt terugbetaling vooral een ontwerpvraag. Vier dingen bepalen of het soepel loopt:

1. Eén beleid, overal hetzelfde: de regel die op de website staat, is de regel die je systeem uitvoert en die de infobalie ziet. Handmatige uitzonderingen zijn het begin van elk verschil in je kas.
2. Een aanvraagstroom, geen mailbox: bezoekers vragen hun restsaldo aan met bandjenummer en rekeninggegevens, en zien de status van hun aanvraag. Zonder die stroom eindigt het in een spreadsheet met honderden regels en een vrijwilliger die overboekingen doet.
3. Uitbetalen in batches: bundel de goedgekeurde aanvragen tot één betaalopdracht in plaats van losse overboekingen, en leg per aanvraag vast welke batch hem heeft meegenomen.
4. Denk aan het randgeval van de afgelasting: gaat het evenement niet door terwijl er al is opgewaardeerd, dan heb je in één klap een volledige terugbetaalronde nodig. Dat pad wil je niet voor het eerst ontwerpen op de dag dat het nodig is.

Eén detail dat geregeld wordt vergeten: niet-besteed saldo is geen gewone omzet. Als een munt bij meerdere btw-tarieven inwisselbaar is — bier tegen het ene tarief, een T-shirt tegen het andere — dan is het volgens de regels voor vouchers voor meervoudig gebruik pas bij inwisseling duidelijk hoeveel btw erover verschuldigd is. Wat nooit is ingewisseld, is fiscaal iets anders dan een verkocht biertje. Je administratie moet die twee dus uit elkaar kunnen houden, en dat lukt alleen als het systeem opwaarderingen en bestedingen als losse gebeurtenissen vastlegt in plaats van als saldomutaties.

De regels achter je eigen munteenheid

Zodra je geld van bezoekers aanneemt en daar iets voor teruggeeft dat op geld lijkt, komt de vraag op of je een vergunning nodig hebt. Voor het typische evenement is het antwoord nee, maar de reden daarvoor is het waard om te kennen.

De Europese betaaldienstenrichtlijn kent een uitzondering voor beperkte netwerken: betaalmiddelen die alleen bruikbaar zijn binnen een afgebakende groep aanbieders of voor een beperkt assortiment. Een festivalmunt die alleen op dat terrein bij die verkopers geldig is, past daarin. In Nederland staat die uitzondering in artikel 1:5a van de Wet op het financieel toezicht. Er zit wel een grens aan: is de totale transactiewaarde in het netwerk over de voorgaande twaalf maanden hoger dan één miljoen euro, dan moet je je beroep op de uitzondering melden bij De Nederlandsche Bank, met een beschrijving van je activiteiten en een onderbouwing waarom de uitzondering opgaat.

Die grens is voor een middelgroot meerdaags evenement sneller in zicht dan het lijkt, zeker als je meerdere edities per jaar draait. Reken er dus aan het begin van het traject aan in plaats van achteraf, en zorg dat je systeem de totale transactiewaarde over een voortschrijdende periode van twaalf maanden kan opleveren — anders kun je die onderbouwing niet eens maken.

Twee dingen halen je juist wél uit de uitzondering. Laat je bezoekers hun saldo ook buiten het terrein gebruiken, of laat je hen onderling saldo overmaken, dan is het geen beperkt netwerk meer maar een betaaldienst. Dat is precies de reden dat "je kunt je credits ook bij onze partnerlocaties in de stad besteden" een leuk idee is met een zware staart. Hoe die grens ook speelt bij platformen die geld voor derden vasthouden, beschreef ik eerder in split payments.

Afrekenen met barpartners en de boekhouding

Op een evenement staat vrijwel nooit alleen jouw eigen personeel achter de tap. Er zijn foodtrucks, een cateraar, een merchandisestand, misschien een goed doel met een eigen bar. Die willen na afloop hun geld, en ze willen het onderbouwd.

Behandel dat daarom als een eigen geldstroom en niet als een rapportageknop. Concreet betekent dat: elke transactie draagt de verkoper waar hij hoorde, elk leesapparaat is aan één verkooppunt gekoppeld, en correcties horen bij de verkoper waar ze thuishoren. Dan is de afrekening na afloop een optelsom uit je grootboek in plaats van een reconstructie uit exportbestanden.

• Drie stromen, apart bijhouden: wat bezoekers hebben opgewaardeerd, wat ze hebben besteed en bij wie, en wat je hebt terugbetaald. Die drie sluiten alleen op elkaar aan als ze los zijn vastgelegd.
• Maak verschillen zichtbaar tijdens het evenement: een apparaat dat sinds gisteren niet heeft gesynchroniseerd is een probleem dat je nú wilt zien, niet maandag.
• Koppel door naar je boekhouding: de dagomzet per verkooppunt hoort automatisch in je boekhoudpakket te landen, inclusief het onderscheid tussen opgewaardeerd en besteed saldo.
• Houd de tegenboeking in beeld: opwaarderingen die met iDEAL of kaart zijn gedaan, kunnen nog worden teruggeboekt nadat het saldo al is uitgegeven. Dat is geen theoretisch geval bij grote evenementen.

Valkuilen die ik het vaakst zie

• De demo op kantoor: alles werkt op een bureau met wifi. Test op het terrein, met de generator, met de apparaten die je echt gaat gebruiken, en trek halverwege de stekker eruit.
• Geen plan voor een verloren bandje: bij saldo op de chip is dit een principiële vraag die je vóór de verkoop beantwoordt, niet bij de eerste huilende bezoeker.
• Opwaarderen alleen digitaal: niet iedere bezoeker heeft een smartphone met bereik of een bankpas bij zich. Een bemand opwaardeerpunt is geen restcategorie maar basisvoorziening — en zelfbedieningszuilen vallen bovendien onder de toegankelijkheidseisen uit de European Accessibility Act.
• Saldo als getal in plaats van als reeks gebeurtenissen: wie alleen het huidige saldo opslaat, kan achteraf niets meer uitleggen. Boek elke mutatie apart en leid het saldo daaruit af.
• Terugbetaling vergeten te begroten: de aanvragen komen dagen na afloop binnen, precies wanneer het team leeg is. Plan die periode in als onderdeel van het evenement.
• Alles bij één leverancier: huur je een compleet systeem, spreek dan vooraf af dat je je eigen transactiedata in bruikbare vorm terugkrijgt. Zonder die afspraak begin je elk jaar opnieuw zonder historie.

Mijn kijk op cashless op evenementen

Ik merk dat de discussie vaak wordt gevoerd op het niveau van de bezoeker: is het handig, vinden mensen het vervelend, hoeveel rijen scheelt het. Dat zijn reële vragen, maar ze verhullen de kern. Cashless is voor een organisator vooral een verschuiving in wie het geld wanneer vasthoudt. Je incasseert eerder, je krijgt inzicht dat je met munten en kasgeld nooit had, en je neemt daarvoor een verplichting op je die na het laatste optreden niet ophoudt.

Precies daarom zie ik de meeste projecten misgaan op de nazorg, niet op de barkassa. Het systeem doet het uitstekend drie dagen lang, en wordt daarna beoordeeld op hoe de terugbetalingen verliepen. Dat is oneerlijk maar volkomen begrijpelijk: dat is het enige deel waar de bezoeker nog contact met je heeft als het feest voorbij is.

Wat mij betreft is dat ook het beste criterium voor de bouw-of-huurvraag. Huur je een systeem, dan huur je iemands beleid mee — inclusief hun terugbetaaltermijn, hun kosten en hun tempo. Bouw je zelf, dan is dat jouw keuze, en kun je het verbinden met je ticketing, je toegangscontrole en je administratie zonder telkens bestanden heen en weer te schuiven. Bij een eenmalig evenement is huren bijna altijd verstandiger. Bij een organisatie die jaar in jaar uit dezelfde locaties en dezelfde partners bedient, wordt de rekensom binnen een paar edities anders — vooral omdat de data van al die edities dan van jou blijft.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen terreinsystemen die offline blijven werken en later netjes bijtrekken: transacties als gebeurtenissen met een eigen identificatie, idempotente synchronisatie, een grootboek per verkooppunt en een terugbetaalstroom die je niet handmatig hoeft te draaien. Dat sluit aan op wat we ook doen voor verhuur en reserveringen en voor organisaties die voorraad, verkoop en kassa in één systeem willen hebben.

Loop je tegen de grenzen van een gehuurd systeem aan, of wil je onderzoeken wat er mogelijk is als ticketing, toegang en betalen op één plek samenkomen? Neem contact op voor een vrijblijvend gesprek.