Archief - Betaalsysteem op fuif

Hallo,

Voor onze fuif volgend jaar willen we enkele aanpassingen doen. Een van die aanpassingen is dat we graag de drankkaarten willen digitaliseren. We zouden heel graag werken meer betaalkaarten.
Alle gegevens (saldo, verbruik, ..) zullen bijgehouden worden in een database. De kaart zou enkel gebruikt moeten worden voor een link tussen de gebruiker en de db.

Vraag:
Hoe kunnen we dit praktisch het best uitvoeren? Hoe verwerken we best de fuifgangers hun bestelling? Welke hardware kunnen we hiervoor gebruiken (liefst zo goedkoop mogelijk aangezien we een jeugdvereniging zijn..).

Mijn (voorlopige) oplossing
Ik had gedacht om kaarten met een RFID chip uit te delen aan de fuifgangers. Wanneer deze aan de toog komen om te bestellen, lezen we met een smartphone (mbv NFC) de ID van de kaart en linken we de order met de database.

Kunnen jullie mij helpen met een oplossing? Alvast bedankt!

PS ik weet niet goed waar ik dit moest plaatsen, aangezien dit een link is tussen hardware en software. Ik heb het maar bij programming gezet omdat dit dan ook een programmeer project is.

Is het dan niet het makkelijkste misschien ineens een bandje met RFID chip te gebruiken? Kost misschien wel wat (tegenover die chips die je op Amazon ofzo koopt )
Of je hebt ook zo van die bandjes met gewoon een barcode of QR-code op. Gewoon elk bandje met een unieke QR code en dat dan scannen en in de databank plaatsen.

Maar wat voor databank zou je gebruiken? Welke software? Zou je die zelf schrijven? En hoe het saldo opladen? Moet dit allemaal manueel worden ingegeven? En is het dan met een bedrag, of heeft alles een vaste waarde (bv 1.5 euro voor een pintje en 3 voor iets speciaal)? Dan is sowieso makkelijker denk ik.

Met RFID uiteraard opletten dat je ze tegoei locked als je niet met een databank moest werken uiteindelijk maar met lokaal saldo. Kameraden in mijn studententijd waren er ook in geslaagd de chips in de studentenkaarten van de KHLeuven te kraken en het saldo aan te passen toen die kaarten net uitkwamen. Hebben dat toen als een werkstuk voor een IT vak uitgeprobeerd en was eigenlijk op een namiddagje klaar. Weet niet meer juist hoe dat in zijn werk ging, maar was dacht ik niet met een database die alles bijhoud. Maar omdat die chips tegenwoordig vaker voorkomen, zijn er misschien wel meerderen die daar al ervaring mee hebben en het snel zouden hebben. En een smartphone is tegenwoordig idd genoeg he

Idd, daarom dat we dan ook niks van gegevens op de kaart zouden zetten, maar alles opslaan in een database. Daar kunnen ze niks aanpassen.
Ik zal eens opzoeken hoeveel zo'n bandje kost, zou ook zalig zijn mocht je die kunnen bedrukken.

Ik weet nog dat we ooit eens hebben prijs gevraagd voor van die plastic bandjes (zonder chip) waar je ook kon zelf iets opzetten en dat dat eigenlijk nog relatief goed meeviel. Stoffen kosten wel redelijk wat, maar die kunnen meestal inderdaad helemaal bedrukt worden, en veel winkels maken dacht ik nog een onderscheid dat je per gebruikte kleur moet betalen.
(maar dat is off topic, want dat is nu niet per se over uw betaalsysteem uiteraard )

Ik weet niet in hoeverre je zelf thuis bent in het programmeren van het hele systeem, want - no offence - de kans is denk ik groot dat het systeem zal plat gaan als je het als een side projectje zelf wilt doen zonder er echt dagelijks mee bezig te zijn (bv. zo iets of dit, maar geen idee of er zo'n lokaal bedrijfje in België is of dat die bedrijven dat voor een relatief kleiner evenement - een fuif - ook regelen)
Er zijn ook bedrijven die dat zo'n formules hebben en dat allemaal regelen. Maar dat hangt volgens mij allemaal af van de grootte van je evenement? Enig idee hoeveel bezoekers er verwacht worden?
Want die systemen met een databank gaan ook zwaar belast worden. Je zegt van alles goedkoop te houden, maar je zal dan best ook zeker een backup server ofzo hebben lopen of een backup methode voor als er op de dag zelf iets mis gaat.

Tegenwoordig wordt voor zo iets altijd nfc gebruikt.
Als ik naar beurzen ga zijn het altijd nfc bandjes of sleutelhangers.

Om te scannen kan je dan ofwel smartphones met android gebruiken (Heb je wel een app nodig die met je db praat) ofwel een pc met een usb bakje.

Hou wel rekening met de kost van eventueel software dat ontwikkeld moet worden.
Als software developer kan ik u zeggen dat dit nogal kan oplopen voor zo iets als dit.

Zouden jullie dit systeem zelf maken?

Als dit het geval is zou ik er niet aan beginnen, dit is een heel ambitieus project waar er veel teveel kan misgaan(wat als je server crasht op de nacht van het event, ...).

Mocht je er toch voor willen gaan zou ik eerst gedurende een jaar alle drankverkoop binnen de vereniging met dit systeem uitvoeren zodat je voor het evenement toch al een relatief goed getest systeem hebt.

Belangrijke vraag die je u eerst moet stellen: waarom wil je dit per se digitaliseren? Sowieso heb je nog altijd een failover nodig voor moest ge technische problemen krijgen, wat meer dan waarschijnlijk nog steeds een gewone papier kaart zal zijn, dus geld uitsparen ga je waarschijnlijk niet doen. Ik zie persoonlijk dan ook niet echt praktische voordelen om zo'n complex systeem uit te gaan werken voor een eenmalig (of jaarlijks) event, behalve dan het prestigegehalte dat ge met een badge kunt zwieren om te betalen

Om uw kost zo laag mogelijk te houden opteer je misschien je best voor één tablet met nfc mogelijkheid waar men de app op uitbouwt met een interne sqlite database.
Op de nfc kaarten wordt enkel een unieke id weggeschreven die uitgelezen kan worden.

Qua technisch voorbeeld richt je je tot landscape mbv de tablet, om meer schermruimte te creëeren tov een smartphone, met +- 3 tabbladen:

tabblad A : creatie van een nieuwe nfc kaart waarop een unieke id wordt weggeschreven;
tabblad B : lees unieke id van nfc kaart in en laad saldo op (fuifganger betaalt hiervoor som aan kassa), eventueel met bijkomende informatie (geslacht, naam, adres) die bijgehouden wordt in database;
tabblad C : orderverwerking en doorvoeren naar bar (ticket afprinten?) voor opeenvolging van consumpties en voor wie het bestemd is + bijhouden in database.

De database kan je achteraf uitlezen met een hulptool zoals:
SQLite Administrator waarmee je nog query's kan schrijven om heel specifieke statistieken te verkrijgen.

Performantie hangt dan enkel nog af van het aantal fuifgangers die uw aantal records bepalen in database.

Prior zei:

Om uw kost zo laag mogelijk te houden opteer je misschien je best voor één tablet met nfc mogelijkheid waar men de app op uitbouwt met een interne sqlite database.
Op de nfc kaarten wordt enkel een unieke id weggeschreven die uitgelezen kan worden.

Qua technisch voorbeeld richt je je tot landscape mbv de tablet, om meer schermruimte te creëeren tov een smartphone, met +- 3 tabbladen:

tabblad A : creatie van een nieuwe nfc kaart waarop een unieke id wordt weggeschreven;
tabblad B : lees unieke id van nfc kaart in en laad saldo op (fuifganger betaalt hiervoor som aan kassa), eventueel met bijkomende informatie (geslacht, naam, adres) die bijgehouden wordt in database;
tabblad C : orderverwerking en doorvoeren naar bar (ticket afprinten?) voor opeenvolging van consumpties en voor wie het bestemd is + bijhouden in database.

De database kan je achteraf uitlezen met een hulptool zoals:
SQLite Administrator waarmee je nog query's kan schrijven om heel specifieke statistieken te verkrijgen.

Performantie hangt dan enkel nog af van het aantal fuifgangers die uw aantal records bepalen in database.

Klik om te vergroten...

Dit lijkt me in de praktijk niet haalbaar omdat iedereen constant via die ene tablet moet gaan voor elke interactie.

nameless zei:

Dit lijkt me in de praktijk niet haalbaar omdat iedereen constant via die ene tablet moet gaan voor elke interactie.

Klik om te vergroten...

Is het haalbaar met behulp van een content provider?
De content provider met de sqlite db is een publieke API op zichzelf ==> app 1 in onderstaand voorbeeld

Dan kan je bijvoorbeeld zeggen:
App 1 = enkel sqlite database met content provider;
App 2 = A insert id;
App 3 = B update id met extra gegevens;
App 4 = C update id met order;
App 5 = C update id met order;

Best niet teveel apps creëeren, want ik denk dat je dan rekening moet houden met meerdere veilige simultane databasebewerkingen over één geheel.



Voorbeeld content provider

Prior zei:

Is het haalbaar met behulp van een content provider?

Klik om te vergroten...

Het systeem op zich bouwen is volgens mij niet het probleem.
Het probleem is dat het systeem maar 1 keer gaat gebruikt worden door veel gebruikers en dat het dan niet mag falen/traag werken/... of je fuif is gedaan. Je kan niet zomaar met papieren bonnetjes beginnen werken als de helft van de zaal al digitale bonnetjes heeft gekocht etc.

Mijn ervaring met dit soort cashless systemen (Tommorowland bijvoorbeeld)

-> Er is véél méér ruimte voor discussie! Heb je donken/vervelende mensen die plots geen saldo meer hebben -> Dit kan moeilijke/vervelende situaties opleveren! En op een kleine fuif kan het al snel gebeuren dat ineens de helft van het volk ineens met elkaar op de vuist gaat.. En dan is het gedaan fuif!

Dus wil je dit echt? Is het niet nog altijd leuker om bonnentjes of een drankkaart op zak te hebben, zodat je visueel ziet wat je nog hebt en kan besteden onder je vrienden? En hoe doe je dat als je een rondje betaald of drank gaat halen voor de hele groep? Je kunt moeilijk zeggen, hier pak mijn bandje maar mee (Constant of fuiven)

En wat doe je op het einde van de avond? Als mensen nog geld op hun kaart hebben? Kunnen ze het terugkrijgen? Ik weet het, met bonnetjes is het hetzelfde verhaal. Maar hier creëer je weer die ruimte voor discussie.. Want zo'n kaart dat zijn geen bonnetjes die je koopt he, dat is geld dat je op je (bank)kaart zet, dus dat blijft mijn eigendom/geld (Mensen!)


Maar dat terzijde.

Ik denk dat het een leuk project is. En het moet niet ingewikkeld gemaakt worden.. Zeker aangezien dit een vrijstaand systeem is. Je hebt (denk ik) geen externe factoren die uw systeem gaan beïnvloeden gewenst of ongewenst. Dus dit maakt het qua veiligheid al een stuk simpeler werken.

Ik zou géén angst hebben voor het "falen" van uw apparatuur. Ik denk dat het wel verstandig is om met twee servers simultaan te werken. Je weet maar nooit natuurlijk. Maar ik denk niet dat er méér dan 5000 bezoekers aanwezig gaan zijn..? En dat kan de gemiddelde database/server wel aan denk ik..


Maar hier enkele punten die in mij opkomen:

- Zorg dat je servers(en mss ook de POS) op een UPS hangen. (De elektriciteit kan al eens falen op een evenement..)
- Hou Log's bij van alle transacties! Zo heb je bewijs van de verrichtingen bij problemen
- Wat ga je doen tegen Skimming? (Ik weet het.. Maar je weet maar nooit..) Vreemde bijnoot, maar het kan gebeuren..
- Zorg voor meerdere POS!
- Test je systeem zorgvuldig! Op alle mogelijke scenarios!
- Zorg voor goede dataverbindingen! Ge niet alles met een draadloos netwerk liggen verbinden. En zorg dat de bezoekers op geen enkele manier aan je toestellen/kabels kunnen.
- Laat de mensen zicht tweemaal identificeren. Een maal voor het ophalen van hun gegevens, tweede maal voor het bevestigen van de transactie
- Zorg voor een visuele weergave voor de bezoeker. Zodat zij een zicht hebben op wat ze betalen.
- Zorg eventueel voor een aparte ruimte waar eventuele problemen kunnen opgelost worden met bezoekers en hun betaalmiddel. Niet tussen het volk en het lawaai of aan de kassa..
- Als je dan toch bezig bent. Misschien dat de mensen online ook al bonnetjes kunnen reserveren (Zoals op alle festivals tegenwoordig.) en deze dan kunnen opladen op het evenement zelf..?

Voor de rest, succes ;-)