test studio purchase permission pay library error compras app android in-app-billing

android - studio - ¿Cuál es el propósito de la "carga útil del desarrollador"? Para qué se puede usar?



pay app billing (4)

Los documentos de Android dicen que está destinado a "información complementaria sobre un pedido", pero al mismo tiempo también dice que no se use para enviar "datos o contenido real".

Entonces, ¿cuál es el propósito de esta "carga útil para desarrolladores"? ¿Por qué existe esta característica? ¿Puede describir un ejemplo práctico del mundo real de cómo puedo usarlo en mi propia implementación de facturación dentro de la aplicación?


Como aromero mencionó, el campo de carga útil del desarrollador tiene un tamaño limitado. Por esta razón, los documentos recomiendan no utilizar esta clave para enviar datos o contenido.

En su lugar, lo que hace es guardar el contenido en una base de datos en algún lugar (por ejemplo, en el dispositivo del usuario o en su propio servidor) y luego colocar el índice del registro en el campo de carga útil del desarrollador. Cuando lo devuelva a través de la intención de transmisión PURCHASE_STATE_CHANGED , puede asociarlo con los datos de su base de datos.

Tenga en cuenta que Market no envía la carga útil del desarrollador cuando utiliza cualquiera de los ID de prueba de los artículos de Android. Tienes que estar usando artículos de compra reales en la aplicación.

Además, de acuerdo con this (todavía no lo he verificado), no recibirá la DeveloperPayload en modo DEBUG. Necesitas firmar tu aplicación en RELEASE MODE para recibir developerPayload.

Finalmente, como comentó a continuación, el JSONObject devuelto (en respuesta a GetPurchaseInformation) ya incluye orderId, productId, purchaseTime y más. Por lo tanto, la "carga útil del desarrollador" debería usarse para cualquier otra cosa que no sea para identificar la compra ... es decir, la respuesta es la opuesta a lo que se ha sugerido a continuación. Lo que puede usar "carga útil del desarrollador" es agregar alguna información que no se encuentre en JSONObject , como detalles adicionales del comprador (por ejemplo, ubicación de GPS si está habilitada, marca y modelo del dispositivo, etc.).


Espero que esto sea de ayuda:

Recomendación de seguridad: cuando envíe una solicitud de compra, cree un token de String que identifique de forma única esta solicitud de compra e incluya este token en developerPayload . Puede usar una cadena generada aleatoriamente como token. Cuando reciba la respuesta de compra de Google Play, asegúrese de verificar la firma de datos devueltos, el ID de pedido y la Cadena de carga de desarrollador. Para mayor seguridad, debe realizar la comprobación en su propio servidor seguro. Asegúrese de verificar que orderId sea un valor único que no haya procesado previamente, y la cadena developerPayload coincide con el token que envió anteriormente con la solicitud de compra.

Más información aquí.


La respuesta aceptada es engañosa y el último párrafo está claramente equivocado. Esto es lo que la documentación oficial tiene que decir al respecto.

Debe pasar un token de cadena que ayude a su aplicación a identificar al usuario que realizó la compra, para que luego pueda verificar que se trata de una compra legítima de ese usuario. Para artículos consumibles, puede usar una cadena generada aleatoriamente, pero para artículos no consumibles debe usar una cadena que identifique de forma única al usuario.

Cuando recupere la respuesta de Google Play, asegúrese de verificar que la cadena de carga útil del desarrollador coincida con el token que envió anteriormente con la solicitud de compra. Como otra precaución de seguridad, debe realizar la verificación en su propio servidor seguro.

La carga útil puede ayudarlo a evitar la identificación de los usuarios que eludieron la API del Servicio de Google Play o su aplicación enviando la carga útil a su servidor donde puede verificar si este usuario alguna vez compró el artículo. Es de suponer que eludir el GPS hará que su aplicación sea engañada con el certificado de compra. Pero si tiene todas las ID de usuario de las personas que realmente compraron honestamente el artículo guardado en su servidor, sería fácil validar la compra según la ID de usuario. El problema aquí: Google hizo imposible confiar en él a menos que tenga a todos los usuarios "registrados" de alguna manera.


Los documentos proporcionan un ejemplo real:

Una cadena especificada por el desarrollador que se puede especificar cuando realiza una solicitud REQUEST_PURCHASE. Este campo se devuelve en la cadena JSON que contiene información de transacción para un pedido. Puede utilizar esta tecla para enviar información complementaria con un pedido. Por ejemplo, puede usar esta clave para enviar claves de índice con un pedido, lo cual es útil si está utilizando una base de datos para almacenar información de compra. Recomendamos que no utilice esta clave para enviar datos o contenido.

Puede usar este campo para identificar el artículo que el usuario está comprando. Cuando emita una solicitud REQUEST_PURCHASE , puede poner información adicional usando DEVELOPER_PAYLOAD . Cuando reciba la respuesta de PURCHASE_STATE_CHANGED , obtendrá esta información nuevamente en el campo developerPayload , para que pueda identificar el pedido.

Este campo está limitado a 256 caracteres y no está encriptado (aunque puede verificar la firma), no está destinado a almacenar contenido real.