- 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 des consommables gérés par le Store à plusieurs reprises sans que votre service ait à les signaler comme consommés ou traité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 traité 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 traité 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’achèvement du traitement
trackingId fournit une validation du traitement compatible avec les nouvelles tentatives.
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 adressée à l’API doit avoir un trackingId unique.
Si la requête d’origine n’a pas abouti, ou si la réponse n’a pas été reçue, le service effectue la transaction demandée lors de la nouvelle tentative de la requête.
Si le traitement a été effectué 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 de second traitement ni de seconde déduction du solde de l’utilisateur.
L’API répond plutôt par un succès, comme si l’élément 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 de confirmation indiquant que la requête a été traitée.
Pour obtenir un exemple, consultez l’exemple de service de jeu.
Lorsque votre requête contient le paramètre includeOrderIds, les comportements suivants sont attendus en fonction du type de produit 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 de requête.
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 d’authentification déléguée.Limitation de sandbox 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 sandbox de développement (non RETAIL), l’authentification à l’aide de l’ID Store utilisateur ou de Microsoft Entra ID n’est pas prise en charge. Dans les environnements sandbox, 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 sandbox RETAIL.
Codes d’erreur d’authentification par ID Store utilisateur
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 ID Store utilisateur 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 ID Store utilisateur. Toutefois, cette méthode d’authentification ne fonctionne pas pour les consommables gérés par le développeur dans les sandbox de développement. Si vous effectuez des tests dans un environnement sandbox, utilisez plutôt l’authentification par jeton XSTS. Pour plus de détails, consultez Authentification par jetons XSTS d’authentification déléguée.
Réponse
Corps de la réponse
L’objet
ConsumeOrderTransaction contient les paramètres suivants.
