Acheter des produits
La procédure principale d'un processus in-app est la transaction qui effectue l'achat en tant que tel. Elle est mise en œuvre par le biais de l'action d'achat, et fonctionne comme suit :
1.Une action d'achat envoie une demande d'achat depuis l'appli à l'app store. Elle contient (i) le nom du produit à acheter, (ii) les détails du compte utilisateur à utiliser pour la transaction, et (iii) le jeton de l'offre qui est requis pour les abonnements de la boutique Android (voir la capture d'écran ci-dessous).
2.L'app store répond par un résumé des données clés du produit et demande une confirmation d'achat. L'utilisateur final sur le client confirme l'achat.
3.L'app store exécute la transaction et envoie les données sur la transaction à l'appli. Ces données d'achat sont stockées dans la source de page $MT_IN_APP_PURCHASE, à l'intérieur d'un élément Root/Purchases/Purchase (voir la capture d'écran ci-dessous).
4.Une fois que les données d'achat ont bien été reçues dans le design, les actions de l'événement OnPurchaseUpdated sont déclenchées. Il s'agit d'actions que vous définissez. Généralement, vous effectuerez les étapes suivantes :
| i. | Vérifiez le code réponse que l'app store envoie sur le succès/l'échec de la demande d'achat. Vous pouvez extraire le code réponse en utilisant la fonction mt-last-in-app-purchase-response-code(). Si l'achat a réussi, la fonction retournera 0. Les autres codes de renvoi varient selon les plate-formes. (Voir la page Autres opérations pour des fonctions de diagnostic supplémentaires, telles que celles qui vérifient si l'utilisateur a annulé l'achat.). |
| ii. | Si nécessaire, enregistrez l'état de l'achat du produit en dehors de la source de page $MT_IN_APP_PURCHASE (soit dans $PERSISTENT, une autre source de page, ou un fichier externe). Vous allez vouloir procéder ainsi si, pour raison ou une autre, vous souhaitez garder un historique séparé de l'activité d'achat. |
| iii. | Activez le produit acheté dans l'appli. Une fois que vous avez vérifié le statut de l'achat, la validité de l'abonnement, une annulation possible etc., de l'achat, vous allez devoir activer le produit en fonction. |
| iv. | Accusé réception de l'achat (par le biais de l'action Accusé réception de l'achat). Vous, en qualité de designer, vous devez déclencher l'action Accusé de réception Achat pour finaliser l'achat pour que le vendeur de l'appli (cela pourrait être vous ou une autre entité) puisse recevoir le paiement. Veuillez noter que l'accusé de réception peut être de deux types différents : (i) pour les abonnements et produits non consommables, et (ii) pour les produits consommables. Pour tout détail, voir l'action Accusé de réception Achat et Exemple de projet : le OnPurchaseUpdated Event. Vous devriez accuser réception de l'achat après avoir activé le produit (voir étape précédente) ; ceci assurerait que l'utilisateur final reçoit l'utilisation de l'achat avant que toute donnée associée à l'achat ne soit éventuellement modifiée. |
Avec l'accusé de réception d'un achat, l'achat in-app sera conclu. Vous pouvez interroger des achats et afficher des informations sur les achats en utilisant les actions Requête achats et Restaurer les achats. Dans le cas de consommables qui ont été achetés pour des appareils Windows, vous pouvez aussi utiliser l'action Obtenir/Rapporter consommable pour interroger combien d'unités de crédit sont encore disponibles (solde) et combien ont été consommées (épuisées).