Paiements et abonnements
Achats intégrés sur les deux stores, vérifiés côté serveur, et paiement à la livraison là où le marché paie en espèces.
Les abonnements se situent là où un seul code rencontre deux stores qui ont chacun leurs règles, leurs reçus et leur fiscalité. Nous faisons passer les achats par une couche de droits commune aux deux plateformes, avec une vérification côté serveur : l'application demande si l'utilisateur a droit à quelque chose au lieu de croire ce que l'appareil affirme. Pour les marchés qui paient en espèces, nous construisons le paiement à la livraison avec le circuit de confirmation et de transporteur dont il a réellement besoin.
Comment ça se passe
- 1
Concevoir le modèle de droits
Ce que chaque formule débloque est défini avant de créer le moindre produit dans les stores, pour qu'un changement de prix plus tard ne demande pas de reconstruire la logique.
- 2
Relier les deux stores à une seule couche
L'application pose une seule question, cet utilisateur y a-t-il droit, et la réponse est la même quel que soit le store par lequel il a payé.
- 3
Toujours vérifier côté serveur
Un reçu est vérifié auprès d'Apple ou de Google côté serveur avant de débloquer quoi que ce soit, ce qui ferme la voie de fraude la plus courante sur les abonnements.
- 4
Traiter les cas limites avant le lancement
Remboursements, délais de grâce, renouvellements échoués et changements de formule sont testés, pas découverts à travers un ticket de support après le lancement.
Questions fréquentes
Que se passe-t-il si quelqu'un tente de simuler un achat ?
Une même application peut-elle proposer abonnements et paiement à la livraison ?
Et si nous changeons nos prix après le lancement ?
Souvent associé à Développement d'application mobile et Plateformes web et e-commerce.
Dites-nous ce qu'il vous faut.
Un paragraphe suffit. Vous aurez une réponse franche sur la pertinence du projet, ce qu'il implique à peu près, et la suite.