¿La versión 3 de la facturación en aplicaciones de Google Play admite reembolsos?

Realmente no hay diferencia entre un artículo consumible y un artículo no consumible en lo que se refiere a Google Play; Esta distinción se basa totalmente en lo que implemente en su aplicación. Por lo tanto, aunque el SKU que está probando esté destinado a ser no consumible (por ejemplo, una actualización premium permanente), con fines de prueba, puede tratarlo como un consumible y consumirlo, para que pueda adquirirse nuevamente.

Un enfoque conveniente es configurar un menú de prueba temporal dentro de la aplicación (por ejemplo, agregando un elemento de menú durante la prueba en el menú de opciones principal de la aplicación) y luego invocar el método consumeAsync () de su instancia IabHelper para El SKU que desea probar comprando de nuevo. Esto consumirá el artículo y así lo hará inmediatamente disponible para la recompra de su dispositivo.

Por supuesto, seguirá queriendo reembolsar la compra de Google Checkout, de modo que no gastará su propio dinero sólo para probar su aplicación.

Me gustaría añadir que consumeAsync () también parece funcionar muy bien para restablecer la prueba SKU android.test.purchased, si está probando con tales valores estáticos.

En cuanto a la actualización del estado de compra para reflejar un reembolso, he experimentado personalmente (y hay muchos informes similares publicados por otros desarrolladores) que iniciar manualmente un reembolso a través de Checkout (por ejemplo, para una compra de prueba de la aplicación TrivialDrive) En un cambio al estado de compra del producto (a INAPP_PURCHASE_STATE_REFUNDED).

(Sabiendo que la miseria ama la compañía, algunos de esos informes adicionales se pueden encontrar en este hilo de la discusión: https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m )

Al menos parte de esto se debe a la caché de datos de compra de Google Play en el dispositivo.

En mi experiencia, reiniciar un dispositivo a veces puede provocar que Google Play actualice su caché de los servidores GP. Por lo tanto, es posible que los cambios debidos a la cancelación o al reembolso de una orden a través de Checkout también puedan detectarse después de un reinicio.

Podría parecer que un período de tiempo tan largo no le haría nada bueno, ya que no puede saber cuándo los usuarios se reiniciarán. Pero de nuevo, usted sabe que cada dispositivo, finalmente, se reiniciará, y por lo tanto, si su preocupación es que un usuario que recibe un reembolso debe ser finalmente bloqueado de usar el producto IAB reembolsado, unos días de retraso no importa mucho, Siempre y cuando eventualmente suceda.

Por supuesto, recuerda que esta noción de que la memoria caché se actualizará en un reinicio es indocumentada y anecdótica (como un buen número de comportamientos de IAB3 y TrivialDrive, hasta ahora). El folklore, lo llaman.

Otra cosa que activa una actualización es cuando el usuario intenta comprar el producto. Tan pronto como se inicia la compra, el sistema debe asegurarse de que el producto ya no pertenece, por lo que actualiza la memoria caché de Google Play. En mi experiencia personal, esto siempre ha ocurrido. Pero nuevamente, esto no es una manera muy práctica de verificar un reembolso, ya que esto implicaría mostrar el diálogo de compra no solicitado, y también un mensaje de error que le dice al usuario "ya eres dueño de esto" (si lo tienen ).

Cuando esto no es útil es cuando el usuario paga por un artículo IAB en uno de sus dispositivos, y luego intenta acceder a ese elemento en un dispositivo diferente que es propiedad de la misma cuenta que se utilizó para comprarlo. La información de compra en ese caso a menudo no se ha almacenado en caché. Pero usted puede poner apenas una pequeña nota en su diálogo de la compra que si el artículo ha sido comprado ya, intentar una re-compra debe hacerlo disponible en el presente dispositivo sin cargo adicional. A veces se necesitan dos intentos de compra (iniciados por el usuario) para obtener finalmente la respuesta IabHelper.BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED. Sí, un poco klugy, pero creo que en términos humanos que funcionará con el resaltado adecuado del mensaje y la redacción apologética del diálogo de confirmación diciéndoles que poseen el elemento, etc :-)).

Como cuestión práctica, puede ver cómo Google podría no querer cada instancia de cada aplicación IAB en el mundo para acceder a sus servidores cada vez que se accede a los datos de compra de la aplicación, especialmente teniendo en cuenta que están aconsejando a los desarrolladores para comprobar lo que ha Cada vez que se inicia la aplicación. También es un problema de rendimiento para tu aplicación, de eso se trata el almacenamiento en caché. Por lo tanto, usted necesita estar al tanto de los disparadores para actualizar la memoria caché, y no he encontrado un solo lugar donde está oficialmente documentado (excepto, suponemos, en el código). Así que prepárate para poner las manos en frente de usted y empezar a sentirse en la oscuridad.

Para obtener más información sobre el almacenamiento en búfer de Google Play, consulta esta página:

¿En qué condiciones se aplican los cambios de servidor de versión 3 de facturación en la aplicación disponibles en los dispositivos cliente?

Tengo en cuenta que en el fragmento de código de tu publicación estás llamando inventory.hasPurchase (SKU_REMOVE_ADS), pero eso sólo te dirá si la compra está en la lista de compras devueltas en el objeto de inventario; No le dirá el estado de la compra para ese SKU. Sé que este es el enfoque utilizado por la aplicación TrivialDrive, pero que la aplicación no se trata de reembolsos y cancelaciones. Para detectar reembolsos y pedidos cancelados, necesitará algo como esto:

 Purchase removeAdsPurchase = inventory.getPurchase(SKU_REMOVE_ADS); if(removeAdsPurchase != null) { int purchaseStateForRemoveAds = removeAdsPurchase.getPurchaseState(); if(purchaseStateForRemoveAds == 1) { //Do cancelled purchase stuff here } else if(purchaseStateForRemoveAds == 2) { //Do refunded purchase stuff here } } 

La buena noticia sobre los reembolsos y pedidos cancelados es que ambos son, AFAIK, enteramente a opción del desarrollador. Por lo tanto, si descubre que los usuarios que obtienen estos pueden continuar utilizando su aplicación durante un largo período después de eso, y si encuentra que muchos usuarios están aprovechando esto, puede decidir si desea continuar proporcionando los reembolsos en todos los casos. Mi mejor conjetura es que no será un problema; Incluso si algún usuario que recibe un reembolso llega a utilizar su aplicación durante un tiempo después de que, que no se ve como un gran problema.

Es para la prueba que usted necesita la capacidad de volver a intentar una compra muy rápidamente, y usar consumeAsync () definitivamente trabaja para ese propósito.

Le sugeriré que utilice IDs de producto estáticos mientras su aplicación esté en fase de desarrollo.

Ahora asegúrate de probar la aplicación con la misma ID de Gmail para la que has reembolsado. Para probar el escenario de reembolso creo que puedes usar android.test.refunded como id de producto.

Si esto no funciona, entonces primero puede comprobar el total de artículos adquiridos y elementos disponibles en google play en el primer lanzamiento de su aplicación y si está recibiendo la misma ID de producto en ambas llamadas (lo que no debería ser el caso Si este es el caso, por favor, informe de este error a google) a continuación, haga una llamada api para hacer el mismo artículo que se consume.

Desde que publicó esta pregunta, se me ha señalado que necesito llamar a getPurchase(...).getPurchaseState() y comprobar su valor. Los valores posibles son 0 (comprado), 1 (cancelado) o 2 (reembolsado).

Sin embargo, en mi caso su retuning todavía 0 (purhcased) aunque el artículo sea consolidado. Estoy publicando esta información aquí en caso de que ayude a otra persona.