reembolso realizar pégala play pedidos navegador historial google direcciones barra android cordova in-app-billing crosswalk

realizar - Android In App Subscription siempre devuelve el recibo inicial, nunca recibo la renovación



reembolso google play music (2)

El recibo original de Google Play es lo que usa para consultar la API de Google Play para obtener información de la suscripción. IAP de Apple funciona de manera muy similar. Para estos mecanismos de compra en la aplicación, usa el subscriptionId del recibo para consultar la API de Google / Apple para determinar la validez de la suscripción.

Estos mecanismos de compra en la aplicación funcionan así debido a la prevención del fraude y los usuarios pueden cambiar la información de suscripción sin la participación de su aplicación.

Esta es la API que le debería interesar:

GET /{packageName}/purchases/subscriptions/{subscriptionId}/tokens/{token} Checks whether a user''s subscription purchase is valid and returns its expiry time.

El flujo general para la validación in-app-purchase es:

  • Validar recibo con Google / Apple
  • Consultar los datos de compra de Google / Apple en función del identificador de suscripción

No debe confiar en los datos devueltos en un recibo en el dispositivo, solo los datos devueltos por una API remota de Apple / Google.

Otra discusión de StackOverflow sobre este tema: Android: validación de recibo de compra en Internet google play

Tengo un problema con mi aplicación de Android Estoy tratando de implementar una suscripción mensual. He creado el IAP, la aplicación está en beta y estoy registrado como tester.

Todo funciona como se espera al comprar la suscripción. Puedo comprarlo como comprobador, lo que significa que la suscripción no se cobra realmente, y también se renueva todos los días.

Pero aquí es donde comienza mi problema. Siempre recibo el recibo original, con el original purchaseTime y purchaseToken . Cada vez que se inicia la aplicación, llamo queryInventoryAsync y espero obtener el último recibo de renovación. Pero siempre recibo el recibo ORIGINAL.

¿Está equivocado mi pensamiento? ¿No debería recibir el recibo renovado con el nuevo orderID ? (como dicen los documentos de Google, debería obtener un orderID como GPA.blabla..0|1|2 Sé que hay algunos mecanismos de almacenamiento en caché, pero he esperado tres días, y sigo recibiendo el pedido original, mientras que debería estar recibiendo la última.

Siempre uso cordova con paso de peatones, y utilizo el siguiente complemento para compras: https://github.com/j3k0/cordova-plugin-purchase . No sé si importa, no debería ser así, ya que utiliza la misma clase IABHelper utilizada por cada otro complemento, pero tal vez es algo malo con su código?

mService.getPurchases(3, mContext.getPackageName(), itemType, continueToken); la respuesta exacta recibida de la llamada a mService.getPurchases(3, mContext.getPackageName(), itemType, continueToken); y contiene los datos incorrectos (recibo original). ¿Por qué? :(

¿Alguien más tenía un problema similar? ¿Es por probar la suscripción? ¿Funcionará cuando realmente compre? Ya comencé a probar con dinero real, pero tomará una semana hasta que la suscripción se renueve.

Muchas gracias.

Editar : borrar la memoria caché de la aplicación Google Play Store no es una opción. No puedo pedirle a mis usuarios que hagan eso. Además, ¡probé esto y no funciona!

Editar 2 ¡ La subscripción de producción (dinero real, sin pruebas) tampoco funciona !. ¡Todavía recibes el recibo original!

Editar 3 No he resuelto este problema todavía. ¿Cuál sería la forma correcta de detectar las renovaciones? ¿Debería ejecutar un cronjob en el back-end y consultar cada suscripción en contra de la API de estado de compra de Google?

Edit 4 Gracias por las respuestas. Ya estoy usando la API de estado de compra en el back-end para determinar si la suscripción se renovó o no. Pero es una mierda, ¿qué pasa si obtengo 100.000 suscripciones? El script que los revisa a todos y consulta la API de Google llevará mucho tiempo ... ¡y es probable que el script se ejecute todos los días!

Pero vamos a aclarar las cosas.

¿Esto significa que la documentación oficial está desactualizada? .

¿ GPA.blabla..0 GPA.blabla..1 renovaciones de estilo GPA.blabla..0 GPA.blabla..1 muertas ?

Editar Actualización del 5 de diciembre de 2016 : He estado ejecutando suscripciones en producción durante un par de meses y aún NO obtengo renovaciones con ..., ... .1. Lo que hice fue configurar un cronjob que se ejecuta diariamente. Pasa a través de mis suscripciones activas y las consulta contra la API de compras de Google. Si la API devuelve una fecha de vencimiento diferente a la guardada en mi base de datos, significa que la suscripción se ha renovado.

Editar la actualización del 6 de julio de 2017 Todavía dependo de mi script diario, que analiza todas las suscripciones y actualiza su estado al consultar a Google con la API de compras https://developers.google.com/android-publisher/api-ref/purchases/subscriptions . Ha estado funcionando bien hasta ahora.

Un consejo rápido: ¡suscripciones de consultas en lotes! Hice algunas pruebas, y pude agrupar hasta 1.000 suscripciones en la misma solicitud. El límite es impuesto por el tamaño máximo de respuesta de la API.


Obtendrás el token de compra del pago inicial. Desde ese token de compra debes consultar el token de suscripción de la API de Google Play a medida que la suscripción a la compra de la aplicación se renueve automáticamente. Por lo tanto, solicitar la API de Google Play es la única forma de obtener el estado de la suscripción en la aplicación. .