BillingMeld : pourquoi la vérification doit être effectuée par le serveur, pas par l'application

L'achat au sein d'une application mobile peut sembler simple pour l'utilisateur. Il clique sur un bouton, confirme le paiement, accède à une fonctionnalité ou un abonnement — et il s'attend à ce que tout fonctionne automatiquement par la suite.

Pour le développeur, derrière ce bouton commence un processus beaucoup plus complexe. Il faut confirmer l'achat lui-même, prendre en compte les renouvellements, la fin d'abonnement, les remboursements, les retours d'opérations, le changement d'appareil et les différences entre les magasins Apple et Google.

Le problème principal surgit lorsque le serveur commence à considérer l'application cliente comme la source de vérité.

Si l’application indique : « Achat effectué », le serveur débloque l’accès et se fie à cet état une fois reçu. Mais le cycle de vie de l’achat ne s’arrête pas là.

Un abonnement peut être renouvelé, le renouvellement automatique désactivé, un paiement peut être remboursé, et l’opération elle-même peut être révoquée par le magasin.

C’est pourquoi, dans BillingMeld, ce n’est pas l’application qui confirme l’achat, mais le serveur.

Le client signale, mais ne décide pas

Dans l’architecture de BillingMeld, l’application mobile n’est pas la principale source d’information sur l’achat.

Le client peut transmettre des données sur une opération effectuée, mais cela ne constitue qu’un point de départ pour la vérification. La décision finale revient à la partie serveur de BillingMeld, qui vérifie les données via les infrastructures d’Apple ou de Google.

C’est une différence fondamentale.

Une application sur un téléphone peut travailler avec un état ancien, ne pas recevoir une mise à jour à temps ou transmettre des données qui ne correspondent plus à l’état actuel de l’achat.

De plus, le client ne doit pas pouvoir décider lui-même si l’accès payant doit lui être accordé ou non.

BillingMeld vérifie par exemple :

• si cet achat existe réellement ;

• si il concerne l’application et le produit en question ;

• si la période payée est toujours en cours ;

• si un renouvellement a eu lieu ;

• si le renouvellement automatique est désactivé ;

• si un remboursement a été effectué ;

• si l’opération a été révoquée ;

• si la période payée n’est pas terminée.

Ainsi, le message du client ne devient pas une preuve d’achat, mais une occasion de vérifier son état réel.

Une source unique de vérité pour les serveurs

Les services connectés n’ont pas besoin d’implémenter une intégration complète avec Apple et Google simultanément.

Ils contactent BillingMeld pour obtenir un état standardisé de l’achat.

Par exemple : accès actif, période payée terminée, renouvellement confirmé, renouvellement automatique désactivé ou achat révoqué.

Cela permet de clarifier la répartition des responsabilités.

Apple et Google sont les sources de l’état de l’opération magasin. BillingMeld vérifie ces données, les normalise et conserve l’état à jour. Le produit final décide de l’accès en se basant sur le statut de BillingMeld.

pour les serveurs des produits, cela signifie un contrat unique plutôt que plusieurs intégrations indépendantes.

Il n’est pas nécessaire d’implémenter séparément les règles d’App Store et Google Play, puis de tenter d’unifier différentes configurations, événements et statuts.

Pourquoi il ne faut pas faire entièrement confiance au client

L’application client fonctionne sur l’appareil de l’utilisateur.

Elle peut être fermée, redémarrée, restaurée à partir d’une sauvegarde, mise à jour ultérieurement ou lancée sur un autre appareil. Elle peut fonctionner avec des données obsolètes ou ne pas recevoir un événement qui a eu lieu après l’achat initial.

Sans intervention de l’utilisateur, cela fait du client une mauvaise source d’état final de l’abonnement.

Par exemple, l’utilisateur a souscrit à un abonnement et a reçu le accès. Plus tard, un remboursement est effectué ou l’opération est révoquée par le magasin.

Si le serveur ne connaît que le message initial du client, il continuera à considérer l’achat comme valable.

Une autre situation : l’utilisateur désactive le renouvellement automatique. La période déjà payée doit continuer à être valable jusqu’à sa fin.

Si le système ne considère qu’un état simplifié « abonnement actif / inactif », il risque de fermer l’accès trop tôt ou, à l’inverse, de le laisser actif une fois que le droit a expiré.

BillingMeld repose sur une autre logique : le client ne confirme pas ses droits. Il signale un événement, et le serveur détermine l’état réel de l’achat.

L’achat n’est pas un événement unique

Une erreur fréquente dans la conception du système de facturation est de considérer l’achat comme un événement unique.

En réalité, il possède un cycle de vie.

Une opération apparaît d’abord. Elle est ensuite confirmée par le magasin. Pour un abonnement, la période payée commence. Plus tard, un renouvellement peut avoir lieu.

L’utilisateur peut désactiver le renouvellement automatique mais continuer à utiliser l’abonnement jusqu’à la fin de la période déjà payée.

Le paiement peut échouer lors du prochain renouvellement.

Un remboursement peut être effectué.

En certains cas, l’achat peut être révoqué.

Il ne suffit donc pas d’avoir la preuve que « cet achat a existé à un moment donné ».

Le serveur doit comprendre ce qui se passe avec l’achat à l’instant présent.

Les retours et révocations ne passent pas inaperçus

Cette nécessité est particulièrement évidente dans le cas des remboursements et des révocations.

Un achat initial pouvait être parfaitement valable. L’utilisateur a effectivement payé et a obtenu l’accès.

Mais par la suite, l’état de l’opération a changé.

Lorsque BillingMeld reçoit une mise à jour, il actualise son propre état d’achat et, si besoin, vérifie à nouveau via le magasin.

Ensuite, le service connecté travaille avec le nouvel état.

De cette façon, l’application ne continue pas à faire confiance à la déclaration initiale plusieurs semaines ou mois plus tard.

Si le magasin considère que le droit associé n’est plus valable, BillingMeld en reflète l’état.

Annulation d’abonnement et fin d’accès : pas la même chose

Une distinction importante existe ici.

Si l’utilisateur désactive le renouvellement automatique, cela ne signifie pas nécessairement que l’accès doit être coupé immédiatement.

La période payée en cours peut continuer à fonctionner.

Dans ce cas, BillingMeld doit enregistrer que le renouvellement est désactivé, tout en conservant la date de fin de la période déjà payée.

Ce n’est qu’après la fin de cette période que l’accès cesse d’être actif, sauf si un nouveau renouvellement est confirmé.

C’est un exemple illustrant que le simple booléen subscription = true ne permet pas la gestion complète de l’abonnement.

L’état de l’abonnement est toujours lié au temps et aux événements de son cycle de vie.

Le renouvellement est aussi une vérification distincte

Une souscription ne se termine pas au premier paiement.

Le serveur doit vérifier si un renouvellement a eu lieu et si la période suivante confirmée par le magasin est toujours valide.

BillingMeld surveille ces changements et met à jour l’état de l’abonnement.

Si le renouvellement est confirmé, le droit d’accès perdure.

Si le paiement n’a pas été effectué ou si le magasin ne confirme plus la période suivante, le système ne doit pas simplement prolonger l’accès d’office.

Pour l’utilisateur, cela doit apparaître comme une prolongation précise : l’accès doit durer aussi longtemps que la période payée en cours.

Pour les développeurs, cela signifie que la même logique de renouvellement ne doit pas être réimplémentée dans chaque application.

Un scénario typique

L’utilisateur souscrit à un abonnement via une application mobile.

Le client transmet les informations d’achat à BillingMeld. Mais cet envoi ne constitue pas encore une preuve définitive de confirmation.

BillingMeld vérifie la transaction via le magasin concerné.

Si l’App Store ou Google Play confirme l’achat et que son statut respecte les règles du produit, BillingMeld enregistre le droit actif.

Le service connecté fournit alors à l’utilisateur les fonctionnalités payantes.

Ensuite, l’état continue à vivre indépendamment du message initial du client.

Si l’abonnement est renouvelé, BillingMeld prend en compte le nouveau paiement.

En cas de désactivation du renouvellement automatique, la période en cours reste valable jusqu’à sa fin.

En cas de remboursement ou de révocation, l’état est à nouveau modifié.

Dans ce modèle, l’application ne stocke pas une « vérité » séparée sur l’achat. Elle travaille avec un état qui est confirmé et conservé par BillingMeld.

Que se passe-t-il en cas de changement d’appareil

Ce modèle serveur est particulièrement utile lorsque l’utilisateur change de téléphone ou réinstalle l’application.

Le droit d’achat ne doit pas dépendre uniquement du fait que l’appareil initial ait enregistré une transaction réussie.

Inversement, la réinstallation ne doit pas supprimer le droit confirmé de l’utilisateur.

Si l’état d’achat est stocké côté serveur et lié à une opération validée par le magasin, un nouvel appareil peut en obtenir l’état actuel via le serveur.

C’est une autre raison pour ne pas stocker la logique d’accès uniquement dans le client mobile.

Ce que cela apporte aux développeurs

Pour une équipe qui lance plusieurs applications mobiles ou travaille sur iOS et Android simultanément, la facturation devient rapidement une infrastructure séparée.

Il faut prendre en compte :

• différents formats de données Apple et Google ;

• la confirmation de l’achat initial ;

• les renouvellements d’abonnement ;

• la fin de la période payée ;

• la désactivation du renouvellement automatique ;

• les remboursements ;

• la révocation d’opérations ;

• la réinstallation de l’application ;

• le changement d’appareil ;

• la restauration des achats ;

• les changements d’état sans intervention du client.

BillingMeld externalise cette logique dans une couche spécifique.

Les serveurs produits y travaillent selon un contrat unique, évitant d’interpréter chaque particularité de chaque plateforme séparément.

Cela réduit la duplication de code et diminue surtout le risque que différentes applications d’une même société aient une compréhension discordante d’un même scénario de paiement.

L’essentiel n’est plus le ticket, mais la jouissance effective

Ce qui m’a le plus intéressé dans cette architecture, c’est la transition du contrôle de chaque achat individuel à la vérification de l’état actuel.

La preuve d’un paiement n’apporte pas la réponse à une question fondamentale du produit :

l’utilisateur a-t-il toujours le droit d’accéder à la fonction payante ?

Une opération peut avoir été initialement réussie mais avoir expiré.

Un abonnement peut avoir désactivé le renouvellement automatique mais continuer à donner accès jusqu’à sa fin.

Il peut y avoir un renouvellement confirmé.

Un remboursement peut être effectué.

Le magasin peut annuler l’opération.

Le point central n’est donc plus le ticket ou la réponse initiale du client, mais l’état actuel du droit de l’utilisateur, basé sur l’état confirmé de l’achat.

C’est cet état que BillingMeld transmet aux autres services.

BillingMeld, une frontière entre magasins et produits

Ce modèle crée une frontière architecturale claire.

D’un côté, l’App Store et Google Play avec leurs formats, événements, règles et cycles de vie d’achat.

De l’autre, les applications et services internes, qui ont généralement besoin d’une réponse beaucoup plus simple : quels droits ont l’utilisateur actuellement ?

Entre eux, BillingMeld.

Il reçoit les données magasins, les vérifie, les adapte à son propre modèle, et fournit un résultat normalisé à toute l’infrastructure.

Grâce à cela, il n’est pas nécessaire que les produits connaissent toutes les subtilités de chaque plateforme de paiement.

Pourquoi c’est important pour l’utilisateur

Une architecture de facturation bien conçue doit rester, idéalement, invisible pour l’utilisateur.

Si l’achat est confirmé et la période payée est toujours en cours, l’accès doit fonctionner.

Si l’utilisateur désactive le renouvellement automatique, la période déjà payée ne doit pas disparaître prématurément.

Lorsqu’un renouvellement est confirmé, l’accès doit continuer.

En cas de remboursement ou de révocation, le changement doit être reflété correctement dans le droit d’accès.

Lors d’un changement d’appareil ou de réinstallation, l’utilisateur ne doit pas avoir à prouver à chaque partie de l’infrastructure que l’achat existe vraiment.

En résumé, la règle est simple :

l’application signale l’achat, le magasin fournit l’état, BillingMeld vérifie et normalise cet état, et les autres services prennent leur décision à partir de ces données confirmées.

C’est pourquoi BillingMeld n’est pas simplement un module de paiement supplémentaire.

C’est une couche serveur de confiance entre l’application mobile, les magasins Apple et Google, et les produits qui doivent avoir une compréhension précise des droits payants en vigueur.

Plus d’informations sur le projet : billingmeld.de.