BillingMeld: waarom een server de aankoop moet verifiëren in plaats van de app

In-App aankopen op een mobiel apparaat lijken meestal eenvoudig voor de gebruiker. Ze drukt op de knop, bevestigt de betaling, krijgt toegang tot een functie of abonnement — en verwacht dat de rest automatisch verloopt.

Voor ontwikkelaars begint achter die knop een veel complexer proces. Ze moeten de aankoop zelf bevestigen, verlengingen, einddata, terugbetalingen, operationele feedback, apparaatwisselingen en verschillen tussen Apple en Google in de gaten houden.

Het grote probleem ontstaat wanneer de server begint te geloven dat de client-app de nieuwe bron van waarheid is.

Als de app zegt: “Aankoop voltooid”, opent de server toegang en blijft deze uitgaan van die status. Maar de levenscyclus van een aankoop eindigt hier niet.

Een abonnement kan verlengd worden, automatische verlenging kan uitgeschakeld zijn, betalingen kunnen teruggedraaid worden, en de operatie zelf kan door de winkel ingetrokken worden.

Daarom bevestigt in BillingMeld niet de app, maar de server de aankoop.

De klant meldt, maar beslist niet

In de architectuur van BillingMeld is de mobiele app niet de belangrijkste bron van informatie over aankopen.

De app kan informatie over de transactie doorgeven, maar dit is slechts een checkpunt. De uiteindelijke beslissing ligt bij de serverkant van BillingMeld, die de informatie verifieert via de infrastructuur van Apple of Google.

Dit is fundamenteel anders.

Een app op een telefoon kan oude statusgegevens hebben, geen recente wijziging ontvangen of data doorgeven die niet meer actueel zijn.

Bovendien mag de client niet zelf bepalen of de gebruiker recht heeft op betaalde toegang.

BillingMeld controleert bijvoorbeeld:

• Of de aankoop daadwerkelijk bestaat;

• Of deze betrekking heeft op de juiste app en product;

• Of de betaalde periode nog actief is;

• Of een verlenging heeft plaatsgevonden;

• Of automatische verlenging uitgeschakeld is;

• Of een terugbetaling is gedaan;

• Of de operatie is ingetrokken;

• Of de betaalde periode nog doorloopt.

Op deze manier wordt het bericht van de klant niet gezien als definitief bewijs, maar als aanleiding om de huidige status te controleren.

Één enkele bron van waarheid voor servers

Verbonden diensten hoeven niet zelf een volledige set integraties met Apple en Google te ontwikkelen.

Zij raadplegen BillingMeld en krijgen een genormaliseerde aankoopstatus.

Bijvoorbeeld: toegang is actief, betaalde periode is verlopen, verlenging is bevestigd, automatische verlenging is uitgeschakeld of aankoop is teruggedraaid.

Dit maakt het onderscheid in verantwoordelijkheden duidelijk.

Apple en Google leveren de status van de winkeltransactie zelf. BillingMeld verifieert die gegevens, brengt ze in een gemeenschappelijk model en bewaart de actuele status. Het eindproduct neemt op basis hiervan een beslissing over de toegang.

Voor servers van producten betekent dit één contract in plaats van meerdere losse integraties.

Het is niet nodig om in elke service apart regels voor App Store, Google Play, etc. te coderen en verschillende formaten, gebeurtenissen en statussen te harmoniseren.

Waarom volledig vertrouwen op de client niet mogelijk is

De client-app draait op het apparaat van de gebruiker.

Het kan gesloten worden, opnieuw opgestart, hersteld vanuit een reservekopie, later bijgewerkt of op een ander apparaat gestart worden. Het kan enige tijd werken met verouderde gegevens of zelfs geen recente gebeurtenis ontvangen.

Zelfs zonder tussenkomst van de gebruiker is de client geen betrouwbare bron voor de uiteindelijke status van een abonnement.

Bijvoorbeeld, een gebruiker heeft een abonnement afgesloten en toegang gekregen. Later wordt de aankoop teruggedraaid of wordt de operatie door de winkel ingetrokken.

Als de server alleen weet van de eerste melding van de client, zal deze blijven aannemen dat de aankoop nog geldig is.

In een andere situatie kan de gebruiker automatische verlenging uitschakelen. Het betaalde deel moet dan nog steeds actief blijven tot de einddatum.

Als het systeem alleen een simpele “abonnement aanwezig/niet aanwezig” status gebruikt, kan het te vroeg toegang sluiten of juist blijven doorlaten nadat het recht op gebruik al verlopen is.

BillingMeld is gebaseerd op een andere logica: de client bevestigt niet zijn rechten. Het meldt een gebeurtenis, en de server bepaalt de feitelijke status van de aankoop.

Een aankoop is geen enkel evenement

Een veelgemaakte fout in de betalingsarchitectuur is het beschouwen van een aankoop als een enkel gebeurtenis.

In werkelijkheid heeft het een levenscyclus.

De operatie wordt initieel gedaan. Vervolgens wordt deze door de winkel bevestigd. Voor een abonnement start de betaalde periode. Daarna kan er een nieuwe verlenging plaatsvinden.

De gebruiker kan automatische verlenging uitschakelen, maar nog steeds gebruik maken van het abonnement tot het einde van de betaalde periode.

Een betaling kan niet doorgaan bij een volgende verlenging.

Een terugbetaling kan plaatsvinden.

Soms kan de aankoop worden ingetrokken.

Daarom is het niet genoeg dat de server weet “deze aankoop heeft ooit bestaan”.

Het is belangrijk te weten wat er op dit moment gebeurt.

Het niet opgemerkte annuleren van aankopen

Dit wordt duidelijk wanneer het gaat om terugbetalingen en intrekkingen.

De oorspronkelijke aankoop kon correct geweest zijn. De gebruiker heeft betaald en toegang verkregen.

Maar later is de status gewijzigd.

Als BillingMeld informatie krijgt over die wijziging, actualiseert het de toestand van de aankoop en verifieert indien nodig opnieuw via de winkel.

Het verbonden dienst werkt vervolgens met de nieuwe status.

Hierdoor stopt het niet om te vertrouwen op de eenvoudige “aankoop ooit gedaan” status, maar wordt rekening gehouden met de actuele situatie.

Als de winkel niet meer meent dat het recht nog bestaat, wordt dit weerspiegeld in BillingMeld.

Annulering van abonnement en beëindiging van toegang — niet hetzelfde

Er is een duidelijk onderscheid.

Als een gebruiker automatische verlenging uitschakelt, betekent dat niet automatisch dat de toegang onmiddellijk stopt.

Het betaalde deel kan nog doorlopen.

BillingMeld moet dan aangeven dat verdere verlenging uitstaat, maar ook de einddatum van het huidige betaalde deel aanhouden.

Pas nadat dat voorbij is, wordt de toegang niet meer actief, tenzij er een nieuwe bevestiging komt.

Dit illustreert waarom een eenvoudige boolean subscription = true niet voldoende is voor een goede verwerking.

De status van een abonnement is altijd gekoppeld aan tijd en gebeurtenissen in de levenscyclus.

Verlengingen zijn ook een aparte controle

Een abonnement eindigt niet bij de eerste betaling.

De server moet weten of er een nieuwe verlenging heeft plaatsgevonden en of de volgende betaalde periode daadwerkelijk bevestigd is door de winkel.

BillingMeld volgt zulke wijzigingen en past de status van het abonnement aan.

Als verlenging bevestigd is, blijft het recht op toegang bestaan.

Bij geen bevestiging of als de winkel het volgende termijn niet meer bevestigt, moet het systeem niet automatisch verlengen.

Voor de gebruiker betekent dit dat de toegang gewoonlijk duurt zolang de betaalde periode actief is.

Voor ontwikkelaars betekent het dat dezelfde verlengingslogica niet in elke app opnieuw geïmplementeerd hoeft te worden.

Hoe een typisch scenario eruitziet

Een gebruiker sluit een abonnement af in een mobiele app.

De klant ontvangt informatie over de aankoop en geeft de gegevens door aan BillingMeld. Maar dit bericht is nog geen definitieve bevestiging dat de aankoop officieel bevestigd is.

BillingMeld controleert de transactie via de betreffende winkel.

Als App Store of Google Play de aankoop bevestigt en de status voldoet aan de regels, registreert BillingMeld het actieve recht.

Vervolgens biedt het verbonden systeem de gebruiker de betaalde functies.

De status blijft daarna bestaan, onafhankelijk van het eerste bericht van de klant.

Bij een verlenging wordt de nieuwe betaalde periode meegenomen.

Als de gebruiker de automatische verlenging uitschakelt, blijft de huidige periode nog lopen.

Bij terugbetaling of intrekking wordt de status weer aangepast.

In dit model bewaart de app geen eigen “eigen waarheid” over de aankoop. Het werkt met de status die door BillingMeld wordt bevestigd en opgeslagen.

Wat gebeurt er bij apparaatwissel

Het servermodel is vooral nuttig wanneer een gebruiker van telefoon wisselt of de app opnieuw installeert.

Het recht op de aankoop moet niet enkel bestaan omdat een exemplaar ooit een succesvolle transactie heeft gezien.

En omgekeerd, het opnieuw installeren van de app mag het bevestigde recht niet vernietigen.

Als de aankoopstatus op de server ligt en gekoppeld is aan een bevestigde winkeloperatie, kan het nieuwe apparaat de actuele status opvragen via de server.

Dit is een extra reden om logica over toegang niet alleen in de client te bewaren.

Wat dit oplevert voor ontwikkelaars

Voor teams die meerdere apps uitbrengen of actief zijn op iOS en Android, wordt billing snel een infrastructuurkwestie.

Ze moeten rekening houden met:

• verschillende datavormen van Apple en Google;

• bevestiging van de eerste aankoop;

• verlengingen van abonnementen;

• einddatum van de betaalde periode;

• uitschakeling van automatische verlenging;

• terugbetalingen;

• intrekkingen van operaties;

• herinstallatie van de app;

• wisselen van apparaat;

• herstel van aankopen;

• statuswijzigingen zonder betrokkenheid van de klant.

BillingMeld brengt deze logica onder in een aparte gespecialiseerde laag.

De servers werken met een uniforme contract en hoeven niet zelf alle details van elke winkel te interpreteren.

Dit vermindert duplicatie van code en vermindert de kans dat verschillende apps in hetzelfde bedrijf verschillende interpretaties hebben van hetzelfde betalingsscenario.

De belangrijkste bron is niet de controle, maar het actuele recht

Wat mij het meest aansprak in deze architectuur was de shift van controle op een enkele aankoop naar controle op de actuele status.

De ene transactie op zich zegt op zich niets meer dan dat er ooit een succesvolle betaling was.

De cruciale vraag voor het product is: heeft de gebruiker momenteel recht op de betaalde functionaliteit?

Een aankoop kan een succesvolle initiële betaling hebben gehad, maar de termijn kan geëindigd zijn.

Een abonnement kan geen automatische verlenging meer hebben, maar de betaalde periode is nog niet verlopen.

Er kan een bevestigde verlenging zijn.

Een terugbetaling kan gepleegd zijn.

De winkel kan de operatie intrekken.

Daarom ligt de focus niet op de controlebon zelf, maar op het huidige recht van de gebruiker, gebaseerd op de bevestigde status van de aankoop.

Dit is precies de status die BillingMeld doorgeeft aan andere services.

BillingMeld als grens tussen winkels en producten

Hier ontstaat een duidelijke architecturale scheiding.

Aan de ene kant de App Store en Google Play met hun formaten, gebeurtenissen, regels en levenscycli van aankopen.

Aan de andere kant applicaties en interne diensten, die meestal een veel eenvoudiger antwoord nodig hebben: wat mag de gebruiker nu?

Daartussen ligt BillingMeld.

Het neemt winkelgegevens aan, controleert ze, brengt ze in een eigen model en biedt een genormaliseerd resultaat aan de infrastructuur.

Hierdoor hoeven producten niet alle innerlijke details van elke betaalplatform te kennen.

Waarom dit belangrijk is voor de gebruiker

Voor de gebruiker zou een goede betalingsarchitectuur in principe onzichtbaar moeten blijven.

Als een aankoop bevestigd is en de betaalde periode actief is, moet de toegang werken.

Als de gebruiker automatische verlenging heeft uitgeschakeld, mag de betaalde termijn niet eerder stoppen dan gepland.

Bij een nieuwe succesvolle verlenging moet de toegang doorgaan.

Als de winkel een terugbetaling of terugname bevestigt, moet het systeem de gebruikersrechten correct aanpassen.

Bij apparaatwissel of herinstallatie mag de gebruiker niet handmatig hoeven te bewijzen dat de aankoop bestaat.

De regel wordt voldoende simpel:

De klant meldt de aankoop, de winkel is de externe bron voor de status, BillingMeld verifieert en normaliseert deze, en andere services beslissen op basis van deze bevestigde gegevens.

Daarom is BillingMeld niet zomaar een betaalmodule, maar een serverlaag van vertrouwen tussen de mobiele app, de winkels en de producten die exact moeten weten welke betaalde rechten de gebruiker op dat moment heeft.

Meer over het project: billingmeld.de.