Betaalapps: de volledige gids

Wie 'betaalapp' zegt, denkt aan de apps van banken en aan Tikkie. Wat bedrijven meestal bedoelen, is iets anders: een eigen app waarin de klant of de medewerker kan afrekenen, zonder pinapparaat en zonder factuur achteraf.

Uw app bepaalt wat er betaald wordt en wanneer. De betaaldienst bepaalt hoe het geld van A naar B komt.

Dat onderscheid is niet academisch. Wie geld van klanten ontvangt en doorgeeft aan anderen, of saldo voor klanten bewaart, is een betaaldienst en heeft een vergunning nodig. Dat is een traject van toezicht, kapitaal en rapportage dat voor een gewoon bedrijf niet haalbaar is en ook niet nodig. Een betaaldienst met vergunning doet dat werk; uw app gebruikt hem.

De toepassingen zijn breed. Een sportclub die contributie int via de app. Een glazenwasser die na de klus op de stoep laat betalen. Een festival met een eigen munt op de telefoon. Een groothandel die chauffeurs bij levering laat afrekenen. Een parkeerterrein zonder slagboom. In elk geval is de betaling het sluitstuk van iets anders, en dat andere is wat u bouwt.

Wat het niet is: een eigen portemonnee waarin klanten tegoed opbouwen dat u beheert. Zodra u saldo van klanten bewaart, bent u een elektronischgeldinstelling in de zin van de wet. Er zijn manieren om iets dat op tegoed lijkt te bouwen zonder dat te worden, maar dat vraagt advies voordat u begint.

Betalen in een app kan op vier manieren, en welke bij u past hangt af van wie betaalt, waar hij is en of het eenmalig is.

Verzoek

een link of QR-code die de klant opent en betaalt met iDEAL of zijn bankapp

In de app

de klant rekent af binnen uw app, met iDEAL, kaart of een digitale portemonnee

Terminal

de telefoon van uw medewerker leest contactloos de kaart van de klant

Incasso

de klant geeft een machtiging en u schrijft periodiek af

Het betaalverzoek is de eenvoudigste vorm en vaak genoeg. Uw app maakt een link met bedrag en omschrijving, stuurt die per bericht of toont een QR-code, en ontvangt de bevestiging. De klant hoeft niets te installeren. Voor een bedrijf dat na een klus of levering wil innen, is dit de vorm die het snelst werkt.

Betalen in de app zelf is nodig als de betaling onderdeel is van een groter proces: een bestelling, een boeking, een lidmaatschap. Dan loopt de klant niet naar buiten naar een betaalpagina, maar rekent hij af waar hij is. Technisch is dat een betaaldienst die in uw app is ingebouwd; de gegevens van de klant gaan rechtstreeks naar die dienst, niet naar u.

De telefoon als terminal is de nieuwste vorm. Een gewone telefoon met de app van de betaaldienst leest contactloze kaarten en portemonnees. Voor bedrijven met medewerkers op locatie scheelt dat een apparaat per persoon. Het loopt volledig via de betaaldienst; uw app geeft het bedrag door en krijgt de uitkomst terug.

Incasso is de vorm voor terugkerende bedragen. De klant geeft één keer een machtiging, en daarna schrijft u af. Dat vraagt een vooraankondiging per afschrijving en een proces voor storneringen; zie de gids over abonnementsfacturatie voor de regels.

Drie regels bepalen het ontwerp, en ze zijn alle drie in uw voordeel als u ze vanaf het begin volgt. Wie ze omzeilt, bouwt iets dat geen betaaldienst wil aansluiten.

De regel over kaartgegevens komt van de kaartmaatschappijen en is hard: wie kaartnummers opslaat of verwerkt, valt onder een certificering die voor een gewone app niet haalbaar is. De oplossing is eenvoudig: de betaaldienst toont zijn eigen invoerveld in uw app, en u ziet het nummer nooit. Elke betaaldienst levert dat kant-en-klaar.

Sterke klantauthenticatie merkt de klant als de stap waarin hij zijn bankapp opent of een code invoert. Voor uw app betekent het dat een betaling niet klaar is als de klant op 'betaal' drukt, maar pas als de betaaldienst de bevestiging stuurt. Bouw daarop, en niet op wat het scherm toonde.

Betalen werkt bijna altijd. Wat misgaat, is wat er daarna gebeurt: de klant heeft betaald, de app weet het niet, en de klant krijgt zijn bestelling niet of tweemaal.

Het scenario met de gesloten app is het vaakst de oorzaak van klachten. De klant betaalt in zijn bankapp, komt niet terug in uw app, en ziet geen bevestiging. Uw systeem moet de betaling dan alsnog verwerken zodra de betaaldienst hem meldt, en de klant een bericht sturen. Wie dat niet bouwt, krijgt klanten die twee keer betalen en daarna bellen.

Terugbetalen is het tweede struikelblok. Een terugbetaling moet aan de oorspronkelijke betaling hangen, via de betaaldienst, zodat de klant het geld op dezelfde rekening terugkrijgt en uw administratie de twee tegenover elkaar ziet. Een medewerker die handmatig overmaakt, maakt een gat dat de boekhouding pas bij de jaarafsluiting vindt.

Een betaling die alleen bij de betaaldienst staat, is voor uw bedrijf een los bedrag. Hij moet aan iets hangen en ergens geboekt worden.

De uitbetaling van de betaaldienst is het moment waarop de koppeling met de boekhouding zich bewijst. De dienst betaalt periodiek een totaalbedrag uit, minus zijn kosten, en de boekhouding moet dat kunnen herleiden tot de losse betalingen. Zonder kenmerk per betaling is dat handwerk; met kenmerk is het een export die de accountant zonder vragen accepteert.

Bouw de koppeling met uw eigen proces eerst. Een betaling die niet aan een order hangt, is een probleem voor de klant; een betaling die nog niet in de boekhouding staat, is een probleem voor het einde van de maand. Het eerste is urgenter.

Honderd of honderdduizend betalingen per maand maakt voor de bouw geen verschil; dat verschil zit in de kosten van de betaaldienst. Wat de bouw drijft, is de vorm en de omgeving.

Vorm

een betaalverzoek is klein; betalen in de app met terugmelding en herstel is een proces

Koppelingen

eigen proces, boekhouding en kassa zijn drie stukken werk

Platform

een webapp is één bouw; store-apps met een ingebouwde betaaldienst zijn twee

Herstel

hangende betalingen, terugbetalingen en geschillen vragen schermen die niemand ziet tot het misgaat

Wat meestal meevalt: de betaling zelf. Elke betaaldienst levert kant-en-klare onderdelen die in een dag in een app staan. Wat tegenvalt, is alles eromheen: de terugmelding, het herstel, de boekhouding en het testen met echte kaarten van echte banken. Dat laatste kan niet in een testomgeving en moet met kleine bedragen in het echt.

Reken de doorlopende kosten van de betaaldienst mee in uw beslissing over de vorm. Een betaalverzoek per iDEAL kost iets anders dan een kaartbetaling of een terminaltransactie, en bij veel kleine bedragen telt dat op. De betaaldienst geeft die tarieven; leg ze naast uw gemiddelde bedrag voordat u kiest.

De volgorde begint bij de vraag hoe uw klant betaalt, niet bij de app. De vorm bepaalt de dienst, en de dienst bepaalt wat er te bouwen valt.

1. Kies de vormVerzoek, in de app, terminal of incasso. Vaak begint u met de eenvoudigste en groeit u door.
2. Kies de betaaldienstDie uw vorm ondersteunt, iDEAL doet, en een koppeling met uw boekhoudpakket heeft.
3. Bouw de terugmeldingDe bevestiging van de dienst verwerken, ook als de klant weg is. Dit vóór het betaalscherm.
4. Bouw het betaalschermBedrag, omschrijving, kenmerk, en het invoerveld van de dienst. Nooit een eigen kaartveld.
5. Koppel aan uw proces en de boekhoudingDe betaling aan de order; de ontvangsten met kenmerk naar de administratie.
6. Test met echt geldKleine bedragen, verschillende banken en kaarten, een afgebroken betaling en een terugbetaling.