Effectuer des achats dans une application mobile avec le SDK Flutter
Afficher des paywalls dans votre application mobile est une étape indispensable pour proposer aux utilisateurs l’accès à des contenus ou services premium. Cependant, l’affichage d’un paywall ne déclenche des achats de lui-même que lorsqu’Adapty affiche l’écran — c’est-à-dire un flow, ou un paywall issu de l’ancien Paywall Builder.
Si vous affichez l’écran dans votre propre code, vous devez utiliser une méthode distincte appelée .makePurchase() pour finaliser un achat et déverrouiller le contenu souhaité. Cette méthode constitue le point d’entrée permettant aux utilisateurs d’interagir avec les paywalls et de procéder à leurs transactions.
Si votre paywall comporte une offre promotionnelle active pour le produit qu’un utilisateur souhaite acheter, Adapty l’appliquera automatiquement au moment de l’achat.
Gardez à l’esprit que l’offre de lancement ne sera appliquée automatiquement que si Adapty affiche l’écran.
Dans les autres cas, vous devrez vérifier l’éligibilité de l’utilisateur à une offre de lancement sur iOS. Ignorer cette étape peut entraîner le rejet de votre application lors de la publication. De plus, cela pourrait conduire à facturer le plein tarif à des utilisateurs éligibles à une offre de lancement.
Assurez-vous d’avoir effectué la configuration initiale sans sauter une seule étape. Sans elle, nous ne pouvons pas valider les achats.
Effectuer un achat
Adapty affiche-t-il votre écran ? Pour un flow ou un paywall créé avec le Paywall Builder, les achats sont traités automatiquement — vous pouvez ignorer cette étape.
Vous cherchez un guide pas à pas ? Consultez le guide de démarrage rapide pour des instructions d’implémentation complètes avec tout le contexte nécessaire.
try {
final purchaseResult = await Adapty().makePurchase(product: product);
switch (purchaseResult) {
case AdaptyPurchaseResultSuccess(profile: final profile):
if (profile.accessLevels['premium']?.isActive ?? false) {
// Grant access to the paid features
}
break;
case AdaptyPurchaseResultPending():
break;
case AdaptyPurchaseResultUserCancelled():
break;
default:
break;
}
} on AdaptyError catch (adaptyError) {
// Handle the error
} catch (e) {
// Handle the error
}
Paramètres de la requête :
| Paramètre | Présence | Description |
|---|---|---|
| Product | obligatoire | Un objet AdaptyPaywallProduct récupéré depuis le paywall. |
Paramètres de la réponse :
| Paramètre | Description |
|---|---|
| Profile | Si la requête a réussi, la réponse contient cet objet. Un objet AdaptyProfile fournit des informations complètes sur les niveaux d’accès, les abonnements et les achats uniques d’un utilisateur dans l’application. Vérifiez le statut du niveau d’accès pour déterminer si l’utilisateur dispose de l’accès requis à l’application. |
Remarque : si vous utilisez encore une version d’Apple StoreKit inférieure à v2.0 et une version du SDK Adapty inférieure à v2.9.0, vous devez fournir le secret partagé de l’Apple App Store à la place. Cette méthode est actuellement dépréciée par Apple.
Changer d’abonnement lors d’un achat
Lorsqu’un utilisateur choisit un nouvel abonnement plutôt que de renouveler l’abonnement en cours, le fonctionnement dépend du store :
- Pour l’App Store, l’abonnement est mis à jour automatiquement au sein du groupe d’abonnements. Si un utilisateur achète un abonnement appartenant à un groupe alors qu’il possède déjà un abonnement d’un autre groupe, les deux abonnements seront actifs simultanément.
- Pour Google Play, l’abonnement n’est pas mis à jour automatiquement. Vous devez gérer le changement dans le code de votre application, comme décrit ci-dessous.
Pour remplacer un abonnement par un autre sur Android, appelez la méthode .makePurchase() avec le paramètre supplémentaire :
try {
final subscriptionUpdateParams = AdaptyAndroidSubscriptionUpdateParameters(
'OLD_PRODUCT_ID',
AdaptyAndroidSubscriptionUpdateReplacementMode.immediateWithTimeProration,
);
final result = await Adapty().makePurchase(
product: product,
parameters: AdaptyPurchaseParameters(
subscriptionUpdateParams: subscriptionUpdateParams,
),
);
// successful cross-grade
} on AdaptyError catch (adaptyError) {
// Handle the error
} catch (e) {
// Handle the error
}
Paramètre de requête supplémentaire :
| Paramètre | Présence | Description |
|---|---|---|
| parameters | obligatoire | un objet AdaptyPurchaseParameters dont le champ subscriptionUpdateParams est défini sur un objet AdaptyAndroidSubscriptionUpdateParameters. |
Pour en savoir plus sur les abonnements et les modes de remplacement, consultez la documentation Google Developer :
- À propos des modes de remplacement
- Recommandations de Google pour les modes de remplacement
- Mode de remplacement
CHARGE_PRORATED_PRICE. Remarque : cette méthode est disponible uniquement pour les mises à niveau d’abonnement. Les rétrogradations ne sont pas prises en charge. - Mode de remplacement
DEFERRED. Remarque : le changement d’abonnement effectif n’interviendra qu’à la fin de la période de facturation en cours.
Utiliser les codes de promotion sur iOS
À propos des codes d’offre
Les codes d’offre vous permettent d’accorder des remises ou des essais gratuits à des utilisateurs spécifiques. Contrairement aux offres classiques appliquées automatiquement, les codes d’offre sont distribués en dehors de l’application — par e-mail, réseaux sociaux ou supports imprimés. Les utilisateurs les échangent en saisissant le code dans l’App Store, en suivant une URL de remboursement ou via une boîte de dialogue intégrée à l’application.
Pour configurer des codes d’offre, ouvrez un abonnement dans App Store Connect et accédez à sa section Offer Codes. Vous pouvez créer trois types de codes d’offre :
- Free — l’abonnement est gratuit pendant une durée définie, puis le renouvellement suivant s’effectue au plein tarif.
- Pay as you go — l’utilisateur paie un prix réduit à chaque cycle de facturation pendant une durée définie, puis l’abonnement se renouvelle au plein tarif.
- Pay up front — l’utilisateur paie un prix réduit unique pour toute la durée de l’offre, puis l’abonnement se renouvelle au plein tarif.
Il n’est pas nécessaire d’ajouter des codes d’offre à Adapty. Apple associe chaque transaction pendant la période d’offre à la catégorie du code d’offre. Cela inclut l’échange initial et tous les renouvellements à prix réduit qui suivent. Adapty détecte ce marqueur et enregistre chaque transaction avec la catégorie d’offre offer_code. Une fois la période d’offre terminée et l’abonnement renouvelé au plein tarif, le marqueur n’est plus présent. Vous pouvez filtrer les analytics par le type d’offre Offer Code dans l’Adapty Dashboard.
Résolution des écarts de revenus
Si vous constatez qu’une transaction liée à un code d’offre apparaît dans Adapty au prix plein du produit au lieu du prix réduit, vérifiez les points suivants dans App Store Connect :
- Le code d’offre dispose d’une tarification correctement configurée pour toutes les régions où les utilisateurs peuvent l’échanger.
- Le prix de l’offre est défini pour le pays ou la région spécifique de l’utilisateur. Apple envoie le prix régional dans la transaction. Si aucun prix régional n’est configuré pour l’offre, Apple peut envoyer le prix plein du produit à la place.
Vous pouvez filtrer et vérifier les transactions liées aux codes d’offre dans l’Adapty Dashboard grâce aux filtres Offer Code et Offer Discount Type.
Anciens codes promo (obsolètes)
Apple a abandonné les codes promo pour les achats intégrés en mars 2026. Les codes d’offre les remplacent avec davantage de fonctionnalités : critères d’éligibilité configurables, dates d’expiration et jusqu’à 1 million de codes par trimestre. Si vous utilisiez auparavant des codes promo pour les achats intégrés, passez aux codes d’offre dans App Store Connect.
Les anciens codes promo (limités à 100 par application et par version) accordaient un accès gratuit à un abonnement. Contrairement aux codes d’offre, Apple n’incluait pas les informations de remise dans les transactions de codes promo — il envoyait le prix plein du produit dans le reçu. Par conséquent, Adapty enregistrait ces transactions au prix plein, ce qui provoquait des écarts de revenus entre les analytics Adapty et App Store Connect.
Si vous constatez des transactions historiques au prix plein qui auraient dû être gratuites, il s’agit probablement d’anciens codes promo. Ces codes étant désormais obsolètes, passez aux codes d’offre pour un suivi précis des revenus.
Pour afficher la feuille de saisie de code dans votre application :
try {
await Adapty().presentCodeRedemptionSheet();
} on AdaptyError catch (adaptyError) {
// handle the error
} catch (e) {
// handle the error
}
D’après nos observations, la feuille de saisie des codes de promotion peut ne pas fonctionner de manière fiable dans certaines applications. Nous recommandons de rediriger directement l’utilisateur vers l’App Store.
Pour ce faire, vous devez ouvrir l’URL au format suivant :
https://apps.apple.com/redeem?ctx=offercodes&id={apple_app_id}&code={code}
Achats intégrés promus depuis l’App Store
Les achats intégrés promus sont pris en charge à partir de la version 4.1 du SDK, sur iOS 16.4 ou ultérieur. En dessous d’iOS 16.4, sur Android et en mode observateur, didReceivePromotedPurchaseStream n’émet jamais.
Lorsqu’un utilisateur démarre un achat depuis la page produit de votre App Store et que la transaction est transférée vers votre application, le SDK la finalise automatiquement — l’écran d’achat Apple s’affiche immédiatement, et Adapty traite la transaction comme n’importe quel autre achat. Aucun code de votre côté n’est nécessaire.
Si le produit mis en avant comporte une offre d’abonnement, le SDK l’applique automatiquement lors de l’achat. L’offre est lue depuis l’intention d’achat App Store, qui l’expose sur iOS 18.0 et versions ultérieures. Sur iOS 16.4–17.x, l’achat est effectué au prix de base.
Pour gérer vous-même les achats mis en avant — par exemple pour afficher votre propre écran en premier — abonnez-vous à didReceivePromotedPurchaseStream et passez le produit à makePromotedPurchase :
Adapty().didReceivePromotedPurchaseStream.listen((product) async {
try {
final result = await Adapty().makePromotedPurchase(product: product);
// process the purchase result
} on AdaptyError catch (adaptyError) {
// handle the error
} catch (e) {
// handle the error
}
});
Tant qu’un handler est abonné au stream, le SDK cesse de finaliser les achats promus à votre place. Si votre handler n’appelle jamais makePromotedPurchase, l’achat n’a pas lieu : l’App Store remet le produit à votre application et attend. Le SDK n’intervient pas non plus si votre handler lève une exception.
makePromotedPurchase ne prend aucun paramètre d’achat, car un produit promu provient de l’App Store plutôt que d’un paywall et ne porte aucun contexte de paywall. Elle retourne le même AdaptyPurchaseResult que makePurchase.
Qui complète l’achat est déterminé pour chaque événement, donc un stream que vous écoutez uniquement lorsqu’un écran est monté restitue les achats promus au SDK dès que cet écran disparaît. Vous pouvez vous abonner avant activate, ce qui vous permet de capturer un achat que le store délivre au lancement.
Gérer les plans prépayés (Android)
Si les utilisateurs de votre application peuvent acheter des plans prépayés (par exemple, acheter un abonnement non renouvelable pour plusieurs mois), vous pouvez activer les transactions en attente pour les plans prépayés.
await Adapty().activate(
configuration: AdaptyConfiguration(apiKey: 'YOUR_PUBLIC_SDK_KEY')
..withGoogleEnablePendingPrepaidPlans(true),
);