Guide monétisation

Checklist In-App Purchases et abonnements

Code de paiement et configuration store forment un système. Un SDK correct ne répare pas un produit absent ou une paywall trompeuse.

LaunchLint Academy

17 min de lectureVérifié par l’équipe éditoriale de LaunchLint
Illustration d’un parcours vérifié d’achat et d’abonnement
Les achats intégrés et abonnements échouent rarement à cause d’un seul appel API. Configuration, statut, paywall, transaction, restauration, compte et accès reviewer doivent former un système cohérent.
TL;DR

La réponse courte

  • Les achats intégrés et abonnements échouent rarement à cause d’un seul appel API. Configuration, statut, paywall, transaction, restauration, compte et accès reviewer doivent former un système cohérent.
  • Ce guide fournit une porte de sortie pour Expo et React Native, reliant les stores Apple et Google à des prix clairs, des droits robustes, des tests de cycle et des indications pour l’équipe de validation complètes.
  • Pour la recette finale, utilisez une matrice de droits plutôt qu’une simple capture du paywall. Chaque ligne combine plateforme, produit, état du store, compte dans l’app et accès attendu. Couvrez nouvel achat, restauration, paiement en attente, remboursement, expiration et compte store déjà lié ailleurs. Comparez interface, backend et vérité du store après chaque transition. Le système n’est prêt que lorsque ces trois niveaux convergent à nouveau. Désignez la personne autorisée à résoudre des webhooks contradictoires ou une panne et à lancer une réconciliation sûre. Pendant cette synchronisation, l’accès ne doit pas clignoter, aucun avantage ne doit être accordé deux fois et le support utilise une référence traçable sans reçu sensible. Rejouez la matrice sur iOS et Android, car des modèles proches ont des états, durées et outils différents. Vérifiez aussi monnaies et langues sur petit écran, avec lecteur d’écran et connexion lente. Archivez date, build, produits, comptes de test et résultat, puis retirez les droits d’essai qui pourraient fausser les métriques ou une revue ultérieure.
  • Après la sortie, surveillez achats terminés, latence des droits, erreurs de restauration, remboursements et support par plateforme et produit. Définissez les alertes avant et gardez un runbook de réconciliation sûr. Un bon taux de checkout ne suffit pas si le client paie mais reçoit son accès tard ou ne peut pas restaurer ailleurs. Comparez les métriques avec des événements vérifiés du store, pas un seul événement client. Examinez les premiers cas manuellement et transformez chaque motif récurrent en test automatisé pour la version suivante.

Définir le modèle produit

Classez chaque avantage : consommable, non consommable ou abonnement. Documentez le contenu, la durée et le lien avec compte, plateforme ou identité store.

Produit, client, backend et configuration partagent ce contrat. Une liste informelle d’IDs provoque périodes erronées, doubles droits ou promesses contradictoires.

Contrat

  • Type et avantage clairs
  • Durée définie
  • Propriété expliquée
  • IDs centralisés
  • Responsable nommé

Aligner produits et statuts

Complétez IDs, noms, descriptions, prix, taxes, disponibilité et langues. Apple demande que le premier achat d’un type accompagne une nouvelle version ; vérifiez son statut.

Google Play structure les abonnements avec produits, plans de base et offres. Contrôlez pays, prix, activation et compatibilité. Un ID dans le code n’est pas un produit vendable.

Stores

  • Langues complètes
  • Prix et pays contrôlés
  • Statut prêt
  • Apple soumis correctement
  • Plans Google actifs

Clarifier paywall et consentement

Le paywall affiche prix, période, renouvellement, essai et bénéfice. Lisez le prix localisé du store plutôt que de coder une monnaie. Bouton et titre ne doivent masquer ni coût ni date.

Liez confidentialité et conditions et rendez la restauration visible. Testez monnaies et traductions longues ; périodes tronquées et remises ambiguës posent problème.

Paywall

  • Prix localisé
  • Période visible
  • Essai clair
  • Conditions accessibles
  • Restore visible

Traiter achats et droits

Ne considérez pas un callback client comme vérité durable. Vérifiez côté serveur, associez de façon idempotente et stockez le droit actuel.

Un achat peut être en attente, annulé, remboursé, révoqué ou livré deux fois. Chaque transition doit être rejouable sans double crédit ni perte. Aucun secret dans les logs client.

Pipeline

  • Vérification serveur
  • Idempotence
  • Attente et annulation
  • Refund met à jour
  • Aucun secret client

Tester restauration et changement d’appareil

Les achats non consommables et abonnements actifs se restaurent après réinstallation ou nouvel appareil. Testez même compte store, nouveau login et compte déjà lié.

Prévoyez des messages pour aucun achat, autre compte, store indisponible et vérification en attente. Sans progression visible, Restore paraît cassé.

Restauration

  • Réinstallation
  • Nouvel appareil
  • Nouveau login
  • Conflit de propriété
  • Erreurs visibles

Gérer abonnement et changements

Donnez un chemin clair vers la gestion ou l’annulation dans le store. Affichez plan et statut et ouvrez la bonne destination sans prétendre que l’app a annulé le contrat.

Prévoyez upgrade, downgrade, grâce, relance, expiration et remboursement. Employez le droit vérifié, pas un booléen local, et gérez les limites temporelles.

Cycle

  • Lien de gestion
  • Droit vérifié
  • Upgrade et downgrade
  • Grâce et relance
  • Expiration et refund

Couvrir sandbox, tracks et erreurs

Testez succès, annulation, attente, perte réseau, double livraison, déjà acheté, restauration, remboursement et expiration. Sandbox et tracks accélèrent le temps ; documentez les cycles.

Utilisez un build distribué par le store lorsque signature et association comptent. Notez ID, plateforme, compte, build et résultat sans conserver de données sensibles.

Tests

  • Succès, annulation, attente
  • Double livraison
  • Restore
  • Refund et expiration
  • Perte réseau

Préparer soumission et indications pour l’équipe de validation

Avant soumission, les produits sont prêts et liés à la version. Le reviewer doit atteindre le paywall, acheter et comprendre le bénéfice verrouillé. Gardez backend et compte disponibles.

Les indications pour l’équipe de validation décrivent navigation, login, produit, résultat, restauration et prérequis. Des étapes claires aident, mais ne réparent pas une transaction défaillante.

Revue

  • Produits liés
  • Backend disponible
  • Chemin exact
  • Résultat décrit
  • Restore documenté

Questions fréquentes

Le premier achat accompagne-t-il une version ?

Apple demande que le premier achat d’un type soit soumis avec une nouvelle version ; vérifiez App Store Connect.

Puis-je coder le prix ?

Mieux vaut lire le prix localisé du store pour conserver monnaie et changements corrects.

Le callback client suffit-il ?

Non. Vérifiez et traitez solidement avant d’accorder un droit durable.

Faut-il une restauration ?

Les achats restaurables et abonnements nécessitent un parcours clair et testé.

Comment aider le reviewer ?

Donnez compte, navigation, produit, résultat et gardez backend et produits accessibles.

Sources officielles

Cet article s’appuie sur les sources officielles ci-dessous. Les règles peuvent évoluer : vérifiez leur version actuelle avant chaque soumission.