- Consumible administrado por la Store: Notifique una cantidad como consumida y quítela del saldo de cantidad actual del usuario especificado. Los usuarios pueden volver a comprar consumibles administrados por la Store repetidamente sin que su servicio tenga que notificarlos como consumidos o completados. Para obtener más información, consulte Solicitud de consumo administrado por la Store.
- Consumible administrado por el desarrollador: Notifique un producto consumible como completado para un usuario especificado. Antes de que un usuario pueda volver a comprar un producto consumible administrado por el desarrollador, su aplicación o servicio debe notificar el producto consumible como completado para ese usuario. Para obtener más información, consulte Solicitud de consumo administrado por el desarrollador.
Uso de trackingId para validar la finalización del consumo
trackingId proporciona una validación del consumo segura frente a reintentos.
Si su servicio no recibe una respuesta de confirmación, vuelva a enviar el mismo cuerpo de solicitud.
El servicio reconoce las solicitudes anteriores y trata los reintentos como comprobaciones de confirmación.
Cada solicitud a la API debe tener un trackingId único.
Si la solicitud original no se completó correctamente, o no se recibió la respuesta, el servicio completa la transacción solicitada cuando se reintenta la solicitud.
Si el consumo se completó en una solicitud anterior, la API reconoce la solicitud y envía una respuesta de confirmación.
En este caso, la API no realiza el consumo ni deduce por segunda vez del saldo del usuario.
En su lugar, la API responde con un resultado correcto como si el artículo se hubiera consumido con el saldo restante del usuario.
Por lo tanto, almacene en caché los valores y el trackingId de cada solicitud en su servidor o en sus registros hasta que reciba una respuesta de confirmación de que la solicitud se completó.
Para ver un ejemplo, consulte el ejemplo de Game Service.
Cuando la solicitud incluye el parámetro includeOrderIds, se esperan estos comportamientos según el tipo de producto del consumible:
Si usa consumibles administrados por el desarrollador, no puede obtener los identificadores de pedido de una solicitud de reintento.
Requisitos previos
Revise los Requisitos previos para las APIs de servicio a servicio. Esta API admite los tipos de autenticación de Microsoft Entra ID y de X-token de autenticación delegada.Limitación de sandbox para los consumibles administrados por el desarrollador: Cuando se consumen productos consumibles administrados por el desarrollador en un sandbox de desarrollo (no RETAIL), no se admite la autenticación mediante User Store ID o Microsoft Entra ID. En entornos de sandbox, debe usar tokens XSTS de autorización delegada para consumir correctamente productos consumibles administrados por el desarrollador. Esta limitación no se aplica a los consumibles administrados por la Store ni al sandbox RETAIL.
Códigos de error de autenticación con User Store ID
Códigos de error con la autenticación de X-token
Solicitud
Sintaxis de la solicitud
Encabezado de solicitud
Cuerpo de la solicitud
Ejemplos de solicitud de consumo
Los ejemplos siguientes usan un User Store ID para la autenticación y requieren el objeto beneficiary en el cuerpo JSON de la solicitud.Solicitud de consumo administrado por la Store
Solicitud de consumo administrado por el desarrollador
El ejemplo siguiente usa la autenticación con User Store ID. Sin embargo, este método de autenticación no funciona para los consumibles administrados por el desarrollador en sandboxes de desarrollo. Si está realizando pruebas en un entorno de sandbox, use en su lugar la autenticación con tokens XSTS. Consulte Autenticación mediante tokens XSTS de autenticación delegada para obtener más detalles.
Respuesta
Cuerpo de la respuesta
El objeto
ConsumeOrderTransaction contiene los parámetros siguientes.
