Tikkie zelf, het verplaatsen van geld via iDEAL, bouw je niet na: dat is een gereguleerde betaaldienst die ABN AMRO en betaalproviders als Mollie al hebben opgelost. Wat je wel bouwt is de flow eromheen, een betaalverzoek maken, delen, status bijhouden en herinneren, toegespitst op één context zoals een vereniging, een horecarekening of een ZZP-factuur. Wat dat kost hangt vooral af van hoeveel van die flow kant-en-klaar is en hoeveel maatwerk. OneDayBuild is niet verbonden aan ABN AMRO of Tikkie.
Onder de laag van groepjes en lijstjes zit een kleine, scherpe kernflow.
Tikkie draait in de kern om vier stappen. De afzender maakt een betaalverzoek aan met een bedrag en een omschrijving. Die wordt omgezet in een link die je deelt via WhatsApp, sms, mail of een QR-code, zonder dat de ontvanger de app hoeft te installeren. De ontvanger opent de link, kiest zijn bank en betaalt met iDEAL. En de afzender ziet in een overzicht wie al heeft betaald en wie nog niet, met de mogelijkheid om een herinnering te sturen.
Daaromheen zit franje die voor de meeste niches niet nodig is: Tikkie Groepje voor het automatisch verdelen van een gezamenlijke rekening tussen vrienden, verjaardagslijstjes, en een aparte zakelijke variant met een eigen API voor bedrijven die betaalverzoeken in hun eigen systeem willen verwerken. Voor een gerichte versie, bijvoorbeeld voor een vereniging, trek je alleen de kernflow eruit en bouw je de rest rond je eigen administratie.
Het grootste deel van wat Tikkie doet, koop je in als bouwsteen, je ontwikkelt het niet zelf.
Hoe meer van de rechterkolom in jouw geval vaststaat, bijvoorbeeld omdat de verdeling altijd gelijk is en er maar één administratie bestaat, hoe kleiner het bouwwerk. Hoe specifieker de uitzonderingen, hoe meer er verschuift van kant-en-klaar naar maatwerk.
Niet de techniek van het betalen is het lastige onderdeel, maar wie waarvoor verantwoordelijk is.
Zodra je zelf geld tijdelijk vasthoudt of doorsluist tussen partijen, bijvoorbeeld door eerst te verzamelen op een eigen rekening en pas later uit te betalen, val je onder toezicht van De Nederlandsche Bank. Voor het aanbieden van een betaaldienst is dan in beginsel een vergunning als betaalinstelling nodig, of moet je onder een partij werken die die vergunning al heeft. Providers zoals Mollie zijn daarvoor al bij DNB geregistreerd en laten betalingen rechtstreeks van betaler naar ontvanger lopen. Zolang jouw applicatie zelf geen geld aanraakt en alleen de interface eromheen bouwt, blijf je daarbuiten.
De kosten zitten dan in een aantal factoren die per situatie verschillen: hoeveel varianten van groepsverdeling je ondersteunt, hoeveel systemen je moet koppelen zoals een ledenadministratie of een boekhoudpakket, hoe strikt de herinneringslogica moet zijn, en hoeveel mensen tegelijk een verzoek moeten kunnen aanmaken. Voor een evenement met een eenmalige piek is dat een ander vraagstuk dan voor een vereniging die het jaar rond contributie int.
Niet het hele model, maar de kernflow met een echte betaalkoppeling in testmodus.
Een voorbeeldscenario voor een vereniging: de penningmeester wil niet langer losse overschrijvingen natrekken voor de jaarlijkse contributie, maar één link die het overzicht bijhoudt.
Welke situatie staat centraal, een ledenlijst, een tafelrekening of een factuur, en welk deel van de flow moet die dag al werken.
De Mollie-testomgeving aansluiten voor de betaalverzoeken, met dummy iDEAL-banken om mee te betalen.
Verzoek aanmaken, link versturen, status bijhouden en een herinnering inbouwen voor wie nog niet betaald heeft.
Een paar testbetalingen vanuit de doelgroep zelf, om te zien of de flow logisch aanvoelt voordat er verder wordt gebouwd.
Aan het eind van die dag ligt er geen schets, maar een werkende flow die je aan een paar leden of aan het bestuur kunt voorleggen.
Wil je vooraf weten of jouw betaalidee zich leent voor zo'n dag, dan geeft de kan-dit-in-1-dag-check daar richting aan.
Dit model is niet voor elke situatie de juiste keuze.
Niet zonder vergunning. Zodra je geld van de één ontvangt en pas later aan een ander uitbetaalt, val je onder toezicht van DNB als betaalinstelling. De gangbare oplossing is betalingen rechtstreeks laten lopen tussen betaler en ontvanger via een provider zoals Mollie, zodat je zelf nooit geld aanraakt.
In de praktijk weinig: beide brengen de ontvanger naar een iDEAL-betaalscherm. Het verschil zit in wat eromheen gebeurt, zoals status bijhouden, automatisch herinneren en een bedrag over een groep verdelen.
Nee. Een betaalprovider zoals Mollie of Adyen regelt de iDEAL-koppeling en is daarvoor zelf bij DNB geregistreerd. Jij sluit een overeenkomst met de provider, niet met iedere bank apart.
iDEAL werkt alleen met Nederlandse bankrekeningen. Voor andere landen is een aanvullende betaalmethode nodig, die dezelfde provider vaak ook aanbiedt, maar dat vraagt om een aparte scope.
Vooral de context. De bestaande app kent jouw ledenlijst, tafelindeling of factuurnummers niet, dus moet je na het betalen alsnog handmatig combineren. Een eigen versie koppelt het betaalverzoek direct aan die administratie.
Een werkende flow met een echte testbetaling in de Mollie-testomgeving, die je aan een paar mensen uit je doelgroep laat zien om te checken of de indeling en de herinneringen logisch aanvoelen, voordat er verder wordt gebouwd.
In één werkdag bouwen we een werkende betaalverzoek-flow met een echte testbetaling, toegesneden op jouw vereniging, horecazaak of facturatie, zodat je 'm kunt laten zien aan de mensen voor wie hij bedoeld is.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.