- Consommable géré par le Store : Signalez une quantité comme consommée et retirez-la du solde de quantité actuel de l’utilisateur spécifié. Les utilisateurs peuvent racheter les consommables gérés par le Store à plusieurs reprises sans que votre service ait à les signaler comme consommés ou exécutés. Pour plus d’informations, consultez Requête de consommation gérée par le Store.
- Consommable géré par le développeur : Signalez un produit consommable comme exécuté pour un utilisateur spécifié. Avant qu’un utilisateur puisse racheter un produit consommable géré par le développeur, votre application ou votre service doit signaler le produit consommable comme exécuté pour cet utilisateur. Pour plus d’informations, consultez Requête de consommation gérée par le développeur.
Utilisation de trackingId pour valider l’exécution
trackingId permet une validation de l’exécution sécuritaire en cas de nouvelle tentative.
Si votre service ne reçoit pas de réponse de confirmation, renvoyez le même corps de requête.
Le service reconnaît les requêtes antérieures et traite les nouvelles tentatives comme des vérifications de confirmation.
Chaque requête à l’API doit avoir un trackingId unique.
Si la requête d’origine n’a pas réussi ou si la réponse n’a pas été reçue, le service effectue la transaction demandée lors de la nouvelle tentative.
Si l’exécution a été effectuée lors d’une requête précédente, l’API reconnaît la requête et envoie une réponse de confirmation.
Dans ce cas, l’API n’effectue pas une deuxième exécution ni une deuxième déduction du solde de l’utilisateur.
L’API répond plutôt par un succès, comme si l’article avait été consommé, avec le solde restant de l’utilisateur.
Par conséquent, mettez en cache les valeurs et le trackingId de chaque requête sur votre serveur ou dans vos journaux jusqu’à ce que vous receviez une réponse confirmant que la requête a été exécutée.
Pour un exemple, consultez le Game Service Sample.
Lorsque votre requête contient le paramètre includeOrderIds, les comportements suivants sont attendus selon le type de produit du consommable :
Si vous utilisez des consommables gérés par le développeur, vous ne pouvez pas obtenir les ID de commande à partir d’une nouvelle tentative.
Prérequis
Consultez Prérequis pour les API de service à service. Cette API prend en charge les types d’authentification Microsoft Entra ID et X-token avec authentification déléguée.Limitation des bacs à sable pour les consommables gérés par le développeur : Lorsque vous consommez des produits consommables gérés par le développeur dans un bac à sable de développement (autre que RETAIL), l’authentification au moyen d’un User Store ID ou de Microsoft Entra ID n’est pas prise en charge. Dans les environnements de bac à sable, vous devez utiliser des jetons XSTS d’autorisation déléguée pour consommer correctement les produits consommables gérés par le développeur. Cette limitation ne s’applique pas aux consommables gérés par le Store ni au bac à sable RETAIL.
Codes d’erreur de l’authentification par User Store ID
Codes d’erreur lors de l’utilisation de l’authentification X-token
Requête
Syntaxe de la requête
En-tête de la requête
Corps de la requête
Exemples de requêtes de consommation
Les exemples suivants utilisent un User Store ID pour l’authentification et nécessitent l’objet beneficiary dans le corps JSON de la requête.Requête de consommation gérée par le Store
Requête de consommation gérée par le développeur
L’exemple suivant utilise l’authentification par User Store ID. Toutefois, cette méthode d’authentification ne fonctionne pas pour les consommables gérés par le développeur dans les bacs à sable de développement. Si vous effectuez des tests dans un environnement de bac à sable, utilisez plutôt l’authentification par jeton XSTS. Pour plus de détails, consultez Authentification au moyen de jetons XSTS d’authentification déléguée.
Réponse
Corps de la réponse
L’objet
ConsumeOrderTransaction contient les paramètres suivants.
