Vendre des abonnements dans l’app

Pourquoi dans l’app c’est différent

Sur le site publié, l’abonnement passe par la passerelle que vous avez connectée (Stripe, Mercado Pago, Pagar.me). Dans l’app installée depuis un store, c’est une violation des règles des deux stores pour du contenu numérique, et la sanction est le retrait de l’app.

La plateforme ne bascule donc jamais sur la passerelle dans l’app. Soit l’achat par le store existe, configuré et prêt, soit l’app affiche l’état muet. Un bouton qui ouvre le store et échoue est pire que pas de bouton.

Le store garde une commission sur chaque vente, et les deux programmes ont des paliers différents selon le chiffre d’affaires et la durée de l’abonnement. Vérifiez les pages officielles d’Apple et de Google Play avant de fixer votre prix.

Ce qui doit être prêt

1. l’app native publiée, ou au moins configurée dans l’onglet Application ;
2. l’achat dans l’app activé à l’étape Fonctions ;
3. les offres de votre app déjà créées (ce que l’onglet Données appelle des plans, et ce que l’app vend) ;
4. les identifiants de vérification : sur iOS la clé In-App Purchase, sur Android le compte de service Play ;
5. chaque offre reliée à un produit du store, sujet du reste de ce guide.

Relier chaque offre à un produit du store

Dans l’onglet Application, la section des abonnements affiche les offres de votre app à côté de ce que le store possède vraiment, un store à la fois (Google Play et l’App Store sont des catalogues séparés : être relié sur l’un ne dit rien de l’autre). Chaque offre porte un état :

Seul vendable autorise l’achat. La distinction compte : chez Google, l’API répond avec succès alors que le plan de base est encore en brouillon, et l’achat échoue ensuite sur l’appareil avec « article indisponible ».

Sur Google Play

Deux actions, selon l’endroit d’où vous partez :

• Créer dans le store : la plateforme crée le produit et active le plan de base pour vous. Avant de confirmer, vérifiez l’identifiant affiché sous « Sera créé sous » ;
• Lier à un produit existant : si vous avez déjà monté le catalogue dans la Play Console, indiquez l’identifiant du produit et celui du plan de base. La plateforme vérifie et montre les différences entre votre offre et ce que contient le store (prix, période), sans décider à votre place.

Sur l’App Store

Ici la plateforme ne crée pas l’abonnement, et ce n’est pas notre limite : Apple exige que le premier abonnement soit envoyé avec une version de l’app, dans un groupe d’abonnements, avec un prix par territoire et une revue.

Le chemin est de le créer dans App Store Connect puis de le lier ici :

1. dans App Store Connect, ouvrez l’app et allez dans Monetization → Subscriptions ;
2. créez un groupe d’abonnements (le groupe est ce qui permet au client de changer d’offre à l’intérieur) ;
3. créez l’abonnement, avec identifiant, durée et prix ;
4. remplissez tout jusqu’à l’état Ready to Submit ;
5. sur la page de la version de l’app, dans la section des achats intégrés, sélectionnez l’abonnement et envoyez les deux ensemble en revue ;
6. une fois approuvé, revenez à l’onglet Application et reliez l’offre à l’identifiant.

Cela vaut pour le premier abonnement. Dès qu’il y en a un approuvé dans le groupe, les suivants peuvent partir seuls.

Les identifiants sont permanents

Sur les deux stores, l’identifiant d’un produit ne peut être ni renommé ni réutilisé une fois créé. Sur Google Play on ne peut même pas supprimer un abonnement, un plan de base ou une offre : ils restent pour toujours, pour les rapports.

C’est pourquoi l’écran prévient avant de créer, et pourquoi il refuse d’inventer une variante quand l’identifiant est déjà pris : la bonne action est alors de lier, pas d’en créer un autre.

La clé In-App Purchase (iOS)

Vérifier un achat sur iOS utilise une clé différente de celle qui envoie les builds. Elle se génère sous Users and Access → Integrations → In-App Purchase et se connecte dans la section des abonnements elle-même.

Sans elle, le store encaisserait sur l’appareil et la vérification refuserait ensuite : argent déplacé, rien débloqué, et le client avec un reçu en main. C’est pourquoi, sans cette clé, l’app reste muette au lieu de vendre.

Le bouton d’abonnement n’apparaît pas : pourquoi

Le serveur décide cela à un seul endroit, et toujours pour restreindre, jamais pour élargir. Chaque motif est une configuration manquante, et tous se corrigent :

Résiliation et remboursements

Un abonnement de store se résilie par le client, dans le store, pas dans votre app : c’est ainsi sur les deux et cela ne se change pas. Renouvellements, résiliations et remboursements nous parviennent par les notifications du store, et l’accès du client est ajusté à partir de là.

Une conséquence pratique sur Android : un achat que l’app ne confirme pas est remboursé automatiquement par Google au bout de trois jours. La plateforme le confirme dès que la vérification passe, donc le chemin normal s’en occupe déjà ; si un client signale un remboursement sans raison, c’est la première chose à regarder.

L’appareil ne décide jamais

Bon à savoir, car cela explique plusieurs réponses du système : l’identifiant de transaction que l’app renvoie est une affirmation, pas une preuve. Tout ce qui déplace de l’argent (quel produit, pour qui, jusqu’à quand, encore actif) est demandé au store avec l’identifiant du propriétaire de l’app.

C’est ce qui empêche un reçu falsifié de débloquer un accès payant, et aussi la raison pour laquelle un achat prend quelques secondes entre l’acceptation du store et le déblocage dans l’app.

Liens officiels

• Google Play : créer et gérer des abonnements
• Google Play : comprendre abonnements, plans de base et offres
• Apple : envoyer un achat intégré en revue
• Apple : générer des clés In-App Purchase