Summary
Resumen del nuevo modelo de suscripción y la Biblioteca de Facturación de Google Play 5.0
![Kate Qonversion Author](https://framerusercontent.com/images/22TVhXbeNHHY5fcrTOyur7zw.webp)
Kate
May 25, 2022
Durante la conferencia anual I/O, Google presentó su nueva versión principal de la Biblioteca de Facturación de Google Play. Además de las clásicas descontinuaciones y eliminaciones de métodos, también ofrecieron abundante información sobre la nueva arquitectura de las suscripciones. Esta última tiene como objetivo simplificar la forma de crear, gestionar y vender las compras dentro de la app. En este artículo, exploraré las actualizaciones de la Biblioteca de Facturación de Google Play 5.0 y profundizaré en las más interesantes.
![Resumen del nuevo modelo de suscripción y la Biblioteca](https://framerusercontent.com/images/q0ydnf29EyKr8Gq1HPkeEvulxM.jpg)
El nuevo modelo de suscripción
La compra de nuevas suscripciones
Y a propósito del código, en la Biblioteca de Facturación de Google Play 5.0, la clase SkuDetails
ha quedado obsoleta, así como cualquier otra entidad o método que contenga Sku
en su nombre. Ahora, hay que considerar el uso de ProductDetails
para ese fin. Los detalles del producto incluyen información sobre una suscripción. Por ejemplo, sus planes básicos y sus ofertas.
Antes, solicitabas detalles de la suscripción como los que se muestran a continuación:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Copy
Ahora, deberías hacer lo siguiente:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }
Copy
Y, para lanzar el flujo de compra, usabas las siguientes construcciones:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
Mientras que, ahora, deberían parecerse a lo siguiente:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
También puedes echar un vistazo a los ejemplos de migración en la guía de migración oficial de Google. Eso sí, ten en cuenta que hay algunas erratas en sus ejemplos, pero se han corregido aquí.
Veamos los cambios.
Como he mencionado, ahora tienes que utilizar ProductDetails
para solicitar los detalles de la suscripción y el flujo de compra. Además, deberás proporcionar un offerToken
a los parámetros del flujo de facturación, ya que cada ProductDetails
puede contener varias ofertas. Ten en cuenta que la selección de detalles de la oferta (productDetails.subscriptionOfferDetails)
siempre incluye detalles del plan básico (si existe algún plan básico), por lo que incluso si tu suscripción contiene solo un plan básico sin ofertas, seguirá teniendo un offerToken
para la compra.
Puedes observar que el nuevo flujo de compra acepta múltiples ProductDetails
en vez de un SkuDetails
como en la versión anterior. No obstante, si proporcionas más de un ProductDetails
, el flujo terminará con un error. La guía oficial de migración da el ejemplo erróneo sobre el uso de los métodos setProductDetails
y setOfferToken
justo en la clase BillingFlowParams.Builder
, pero solo está disponible el método setProductDetailsParamsList
para estos fines. Parece como si, recientemente, Google hubiera decidido pasar de los detalles de producto únicos a los múltiples. Esto muestra una visión de futuro en la que la facturación admitirá varias compras de suscripción diferentes al mismo tiempo.
El resto del flujo (es decir, el procesamiento de la compra) sigue siendo el mismo que en la Biblioteca de Facturación de Google Play 4.0.
Compatibilidad retroactiva de las suscripciones
Bueno, hasta ahora, todo suena bien, pero ¿qué pasa si no quieres migrar ahora mismo? Google se ha encargado de ello.
A pesar de que Google Play Console ya funciona únicamente con el nuevo modelo de suscripción, todas las suscripciones antiguas se convierten al nuevo formato automáticamente. Por lo tanto, se conserva su retrocompatibilidad con versiones anteriores. Esto quiere decir que verás tus suscripciones en el nuevo formato en Google Console, pero podrás seguir trabajando con ellas de la misma forma en la que lo hacías antes en tu app.
De igual manera, también podrás observar que todas las suscripciones antiguas pasan a ser de solo lectura tras la migración. Por ello, Google te advierte de que la edición inhabilitará la compatibilidad con la API de InAppProducts de esa suscripción.
Es posible que utilices esta API en tu backend para obtener algunos detalles del producto, así que ten cuidado. Y es que, después de hacer editable la suscripción, surgirán errores (como se muestra a continuación) de esa API si intentas obtener información de la suscripción que se ha convertido. Lo mismo ocurrirá con todas las nuevas suscripciones creadas después del 11 de mayo.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}
Copy
Así pues, si utilizas la API de InAppProducts, considera la posibilidad de actualizarla antes de crear nuevas suscripciones o editar las antiguas.
Mientras navegas por la nueva interfaz de suscripciones en Google Play Console, encontrarás etiquetas «retrocompatible» cerca de los planes básicos y las ofertas de las suscripciones. Esto implica que si compras esas suscripciones utilizando SkuDetails
compatibles (como se hace en la Biblioteca de Facturación de Google Play 4.0), comprarás exactamente esos planes básicos u ofertas compatibles. Si solo hay un plan básico compatible, sin ninguna oferta que también lo sea, se comprará ese plan básico. Si hay tanto un plan básico como una oferta compatibles que estén disponibles, en ese caso, si la oferta se puede aplicar al usuario actual, se comprará. Si no, solo se comprará el plan básico. Si quieres, puedes elegir otro plan básico/oferta como retrocompatible con versiones anteriores.
Nota: esta retrocompatibilidad hace referencia a la Biblioteca de Facturación de Google Play, pero no a la API de InAppProducts. Como se ha mencionado anteriormente, si empiezas a utilizar las nuevas funciones (por ejemplo, varios planes básicos u ofertas para una suscripción) o, simplemente, la conviertes de solo lectura a editable, esa suscripción puede seguir siendo retrocompatible para una app, pero no para la API.
Otras actualizaciones
Ha habido varias actualizaciones menores en la Biblioteca de Facturación de Google Play 5.0 que vale la pena mencionar, aunque sea brevemente.
Se ha eliminado el método obsoleto
queryPurchases
de la Biblioteca de Facturación de Google Play 4.0.Ya no hay solicitudes sincronizadas, solo
queryPurchasesAsync
.launchPriceChangeFlow
ha quedado obsoleto: el nuevo flujo de cambio de precios recomendado requiere la confirmación de los clientes a través de la página de suscripciones de Google Play, por lo que se deben utilizar enlaces profundos para navegar por allí en lugar de recurrir al método BillingClient.Se ha añadido el método
setIsOfferPersonalized
para indicar un precio personalizado para los clientes de la Unión Europea siguiendo la Directiva de Derechos del Consumidor. Esta opción añade una línea en la parte inferior de la pantalla de compra de Facturación de Google en la que se indica que el precio se ha personalizado.
El nuevo modelo de suscripción y Qonversion
Mientras trabajamos en la asistencia de la Biblioteca de Facturación de Google Play 5.0, puedes seguir utilizando el SDK de Qonversion para tus compras dentro de la app. Ahora, utilizamos la Biblioteca de Facturación de Google Play 4.0, lo que significa que solo podemos gestionar aquellas suscripciones con planes básicos y ofertas retrocompatibles. Todavía es posible editar las propiedades que estaban disponibles en el modelo de suscripciones anterior, como el precio, el período de gracia, la duración de la prueba, etc., así como crear nuevas suscripciones. Solo hay que asegurarse de que, después, tengas al menos un plan básico retrocompatible y, si es necesario, una oferta retrocompatible. Además, sigue siendo necesario contar con un identificador de suscripción completo para configurar los productos en nuestro centro de productos, no identificadores de planes básicos u ofertas.
Si tienes cualquier consulta, no dudes en comunicárnosla. Estaremos encantados de ayudarte.
Enlaces de interés
Resumen del nuevo modelo de suscripción y la Biblioteca de Facturación de Google Play 5.0
![Kate Qonversion Author](https://framerusercontent.com/images/22TVhXbeNHHY5fcrTOyur7zw.webp)
Kate
May 25, 2022
Durante la conferencia anual I/O, Google presentó su nueva versión principal de la Biblioteca de Facturación de Google Play. Además de las clásicas descontinuaciones y eliminaciones de métodos, también ofrecieron abundante información sobre la nueva arquitectura de las suscripciones. Esta última tiene como objetivo simplificar la forma de crear, gestionar y vender las compras dentro de la app. En este artículo, exploraré las actualizaciones de la Biblioteca de Facturación de Google Play 5.0 y profundizaré en las más interesantes.
![Resumen del nuevo modelo de suscripción y la Biblioteca](https://framerusercontent.com/images/q0ydnf29EyKr8Gq1HPkeEvulxM.jpg)
El nuevo modelo de suscripción
La compra de nuevas suscripciones
Y a propósito del código, en la Biblioteca de Facturación de Google Play 5.0, la clase SkuDetails
ha quedado obsoleta, así como cualquier otra entidad o método que contenga Sku
en su nombre. Ahora, hay que considerar el uso de ProductDetails
para ese fin. Los detalles del producto incluyen información sobre una suscripción. Por ejemplo, sus planes básicos y sus ofertas.
Antes, solicitabas detalles de la suscripción como los que se muestran a continuación:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Copy
Ahora, deberías hacer lo siguiente:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }
Copy
Y, para lanzar el flujo de compra, usabas las siguientes construcciones:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
Mientras que, ahora, deberían parecerse a lo siguiente:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
También puedes echar un vistazo a los ejemplos de migración en la guía de migración oficial de Google. Eso sí, ten en cuenta que hay algunas erratas en sus ejemplos, pero se han corregido aquí.
Veamos los cambios.
Como he mencionado, ahora tienes que utilizar ProductDetails
para solicitar los detalles de la suscripción y el flujo de compra. Además, deberás proporcionar un offerToken
a los parámetros del flujo de facturación, ya que cada ProductDetails
puede contener varias ofertas. Ten en cuenta que la selección de detalles de la oferta (productDetails.subscriptionOfferDetails)
siempre incluye detalles del plan básico (si existe algún plan básico), por lo que incluso si tu suscripción contiene solo un plan básico sin ofertas, seguirá teniendo un offerToken
para la compra.
Puedes observar que el nuevo flujo de compra acepta múltiples ProductDetails
en vez de un SkuDetails
como en la versión anterior. No obstante, si proporcionas más de un ProductDetails
, el flujo terminará con un error. La guía oficial de migración da el ejemplo erróneo sobre el uso de los métodos setProductDetails
y setOfferToken
justo en la clase BillingFlowParams.Builder
, pero solo está disponible el método setProductDetailsParamsList
para estos fines. Parece como si, recientemente, Google hubiera decidido pasar de los detalles de producto únicos a los múltiples. Esto muestra una visión de futuro en la que la facturación admitirá varias compras de suscripción diferentes al mismo tiempo.
El resto del flujo (es decir, el procesamiento de la compra) sigue siendo el mismo que en la Biblioteca de Facturación de Google Play 4.0.
Compatibilidad retroactiva de las suscripciones
Bueno, hasta ahora, todo suena bien, pero ¿qué pasa si no quieres migrar ahora mismo? Google se ha encargado de ello.
A pesar de que Google Play Console ya funciona únicamente con el nuevo modelo de suscripción, todas las suscripciones antiguas se convierten al nuevo formato automáticamente. Por lo tanto, se conserva su retrocompatibilidad con versiones anteriores. Esto quiere decir que verás tus suscripciones en el nuevo formato en Google Console, pero podrás seguir trabajando con ellas de la misma forma en la que lo hacías antes en tu app.
De igual manera, también podrás observar que todas las suscripciones antiguas pasan a ser de solo lectura tras la migración. Por ello, Google te advierte de que la edición inhabilitará la compatibilidad con la API de InAppProducts de esa suscripción.
Es posible que utilices esta API en tu backend para obtener algunos detalles del producto, así que ten cuidado. Y es que, después de hacer editable la suscripción, surgirán errores (como se muestra a continuación) de esa API si intentas obtener información de la suscripción que se ha convertido. Lo mismo ocurrirá con todas las nuevas suscripciones creadas después del 11 de mayo.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}
Copy
Así pues, si utilizas la API de InAppProducts, considera la posibilidad de actualizarla antes de crear nuevas suscripciones o editar las antiguas.
Mientras navegas por la nueva interfaz de suscripciones en Google Play Console, encontrarás etiquetas «retrocompatible» cerca de los planes básicos y las ofertas de las suscripciones. Esto implica que si compras esas suscripciones utilizando SkuDetails
compatibles (como se hace en la Biblioteca de Facturación de Google Play 4.0), comprarás exactamente esos planes básicos u ofertas compatibles. Si solo hay un plan básico compatible, sin ninguna oferta que también lo sea, se comprará ese plan básico. Si hay tanto un plan básico como una oferta compatibles que estén disponibles, en ese caso, si la oferta se puede aplicar al usuario actual, se comprará. Si no, solo se comprará el plan básico. Si quieres, puedes elegir otro plan básico/oferta como retrocompatible con versiones anteriores.
Nota: esta retrocompatibilidad hace referencia a la Biblioteca de Facturación de Google Play, pero no a la API de InAppProducts. Como se ha mencionado anteriormente, si empiezas a utilizar las nuevas funciones (por ejemplo, varios planes básicos u ofertas para una suscripción) o, simplemente, la conviertes de solo lectura a editable, esa suscripción puede seguir siendo retrocompatible para una app, pero no para la API.
Otras actualizaciones
Ha habido varias actualizaciones menores en la Biblioteca de Facturación de Google Play 5.0 que vale la pena mencionar, aunque sea brevemente.
Se ha eliminado el método obsoleto
queryPurchases
de la Biblioteca de Facturación de Google Play 4.0.Ya no hay solicitudes sincronizadas, solo
queryPurchasesAsync
.launchPriceChangeFlow
ha quedado obsoleto: el nuevo flujo de cambio de precios recomendado requiere la confirmación de los clientes a través de la página de suscripciones de Google Play, por lo que se deben utilizar enlaces profundos para navegar por allí en lugar de recurrir al método BillingClient.Se ha añadido el método
setIsOfferPersonalized
para indicar un precio personalizado para los clientes de la Unión Europea siguiendo la Directiva de Derechos del Consumidor. Esta opción añade una línea en la parte inferior de la pantalla de compra de Facturación de Google en la que se indica que el precio se ha personalizado.
El nuevo modelo de suscripción y Qonversion
Mientras trabajamos en la asistencia de la Biblioteca de Facturación de Google Play 5.0, puedes seguir utilizando el SDK de Qonversion para tus compras dentro de la app. Ahora, utilizamos la Biblioteca de Facturación de Google Play 4.0, lo que significa que solo podemos gestionar aquellas suscripciones con planes básicos y ofertas retrocompatibles. Todavía es posible editar las propiedades que estaban disponibles en el modelo de suscripciones anterior, como el precio, el período de gracia, la duración de la prueba, etc., así como crear nuevas suscripciones. Solo hay que asegurarse de que, después, tengas al menos un plan básico retrocompatible y, si es necesario, una oferta retrocompatible. Además, sigue siendo necesario contar con un identificador de suscripción completo para configurar los productos en nuestro centro de productos, no identificadores de planes básicos u ofertas.
Si tienes cualquier consulta, no dudes en comunicárnosla. Estaremos encantados de ayudarte.
Enlaces de interés
Resumen del nuevo modelo de suscripción y la Biblioteca de Facturación de Google Play 5.0
![Kate Qonversion Author](https://framerusercontent.com/images/22TVhXbeNHHY5fcrTOyur7zw.webp)
Kate
May 25, 2022
Durante la conferencia anual I/O, Google presentó su nueva versión principal de la Biblioteca de Facturación de Google Play. Además de las clásicas descontinuaciones y eliminaciones de métodos, también ofrecieron abundante información sobre la nueva arquitectura de las suscripciones. Esta última tiene como objetivo simplificar la forma de crear, gestionar y vender las compras dentro de la app. En este artículo, exploraré las actualizaciones de la Biblioteca de Facturación de Google Play 5.0 y profundizaré en las más interesantes.
![Resumen del nuevo modelo de suscripción y la Biblioteca](https://framerusercontent.com/images/q0ydnf29EyKr8Gq1HPkeEvulxM.jpg)
El nuevo modelo de suscripción
La compra de nuevas suscripciones
Y a propósito del código, en la Biblioteca de Facturación de Google Play 5.0, la clase SkuDetails
ha quedado obsoleta, así como cualquier otra entidad o método que contenga Sku
en su nombre. Ahora, hay que considerar el uso de ProductDetails
para ese fin. Los detalles del producto incluyen información sobre una suscripción. Por ejemplo, sus planes básicos y sus ofertas.
Antes, solicitabas detalles de la suscripción como los que se muestran a continuación:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Copy
Ahora, deberías hacer lo siguiente:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }
Copy
Y, para lanzar el flujo de compra, usabas las siguientes construcciones:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
Mientras que, ahora, deberían parecerse a lo siguiente:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
También puedes echar un vistazo a los ejemplos de migración en la guía de migración oficial de Google. Eso sí, ten en cuenta que hay algunas erratas en sus ejemplos, pero se han corregido aquí.
Veamos los cambios.
Como he mencionado, ahora tienes que utilizar ProductDetails
para solicitar los detalles de la suscripción y el flujo de compra. Además, deberás proporcionar un offerToken
a los parámetros del flujo de facturación, ya que cada ProductDetails
puede contener varias ofertas. Ten en cuenta que la selección de detalles de la oferta (productDetails.subscriptionOfferDetails)
siempre incluye detalles del plan básico (si existe algún plan básico), por lo que incluso si tu suscripción contiene solo un plan básico sin ofertas, seguirá teniendo un offerToken
para la compra.
Puedes observar que el nuevo flujo de compra acepta múltiples ProductDetails
en vez de un SkuDetails
como en la versión anterior. No obstante, si proporcionas más de un ProductDetails
, el flujo terminará con un error. La guía oficial de migración da el ejemplo erróneo sobre el uso de los métodos setProductDetails
y setOfferToken
justo en la clase BillingFlowParams.Builder
, pero solo está disponible el método setProductDetailsParamsList
para estos fines. Parece como si, recientemente, Google hubiera decidido pasar de los detalles de producto únicos a los múltiples. Esto muestra una visión de futuro en la que la facturación admitirá varias compras de suscripción diferentes al mismo tiempo.
El resto del flujo (es decir, el procesamiento de la compra) sigue siendo el mismo que en la Biblioteca de Facturación de Google Play 4.0.
Compatibilidad retroactiva de las suscripciones
Bueno, hasta ahora, todo suena bien, pero ¿qué pasa si no quieres migrar ahora mismo? Google se ha encargado de ello.
A pesar de que Google Play Console ya funciona únicamente con el nuevo modelo de suscripción, todas las suscripciones antiguas se convierten al nuevo formato automáticamente. Por lo tanto, se conserva su retrocompatibilidad con versiones anteriores. Esto quiere decir que verás tus suscripciones en el nuevo formato en Google Console, pero podrás seguir trabajando con ellas de la misma forma en la que lo hacías antes en tu app.
De igual manera, también podrás observar que todas las suscripciones antiguas pasan a ser de solo lectura tras la migración. Por ello, Google te advierte de que la edición inhabilitará la compatibilidad con la API de InAppProducts de esa suscripción.
Es posible que utilices esta API en tu backend para obtener algunos detalles del producto, así que ten cuidado. Y es que, después de hacer editable la suscripción, surgirán errores (como se muestra a continuación) de esa API si intentas obtener información de la suscripción que se ha convertido. Lo mismo ocurrirá con todas las nuevas suscripciones creadas después del 11 de mayo.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}
Copy
Así pues, si utilizas la API de InAppProducts, considera la posibilidad de actualizarla antes de crear nuevas suscripciones o editar las antiguas.
Mientras navegas por la nueva interfaz de suscripciones en Google Play Console, encontrarás etiquetas «retrocompatible» cerca de los planes básicos y las ofertas de las suscripciones. Esto implica que si compras esas suscripciones utilizando SkuDetails
compatibles (como se hace en la Biblioteca de Facturación de Google Play 4.0), comprarás exactamente esos planes básicos u ofertas compatibles. Si solo hay un plan básico compatible, sin ninguna oferta que también lo sea, se comprará ese plan básico. Si hay tanto un plan básico como una oferta compatibles que estén disponibles, en ese caso, si la oferta se puede aplicar al usuario actual, se comprará. Si no, solo se comprará el plan básico. Si quieres, puedes elegir otro plan básico/oferta como retrocompatible con versiones anteriores.
Nota: esta retrocompatibilidad hace referencia a la Biblioteca de Facturación de Google Play, pero no a la API de InAppProducts. Como se ha mencionado anteriormente, si empiezas a utilizar las nuevas funciones (por ejemplo, varios planes básicos u ofertas para una suscripción) o, simplemente, la conviertes de solo lectura a editable, esa suscripción puede seguir siendo retrocompatible para una app, pero no para la API.
Otras actualizaciones
Ha habido varias actualizaciones menores en la Biblioteca de Facturación de Google Play 5.0 que vale la pena mencionar, aunque sea brevemente.
Se ha eliminado el método obsoleto
queryPurchases
de la Biblioteca de Facturación de Google Play 4.0.Ya no hay solicitudes sincronizadas, solo
queryPurchasesAsync
.launchPriceChangeFlow
ha quedado obsoleto: el nuevo flujo de cambio de precios recomendado requiere la confirmación de los clientes a través de la página de suscripciones de Google Play, por lo que se deben utilizar enlaces profundos para navegar por allí en lugar de recurrir al método BillingClient.Se ha añadido el método
setIsOfferPersonalized
para indicar un precio personalizado para los clientes de la Unión Europea siguiendo la Directiva de Derechos del Consumidor. Esta opción añade una línea en la parte inferior de la pantalla de compra de Facturación de Google en la que se indica que el precio se ha personalizado.
El nuevo modelo de suscripción y Qonversion
Mientras trabajamos en la asistencia de la Biblioteca de Facturación de Google Play 5.0, puedes seguir utilizando el SDK de Qonversion para tus compras dentro de la app. Ahora, utilizamos la Biblioteca de Facturación de Google Play 4.0, lo que significa que solo podemos gestionar aquellas suscripciones con planes básicos y ofertas retrocompatibles. Todavía es posible editar las propiedades que estaban disponibles en el modelo de suscripciones anterior, como el precio, el período de gracia, la duración de la prueba, etc., así como crear nuevas suscripciones. Solo hay que asegurarse de que, después, tengas al menos un plan básico retrocompatible y, si es necesario, una oferta retrocompatible. Además, sigue siendo necesario contar con un identificador de suscripción completo para configurar los productos en nuestro centro de productos, no identificadores de planes básicos u ofertas.
Si tienes cualquier consulta, no dudes en comunicárnosla. Estaremos encantados de ayudarte.
Enlaces de interés
Resumen del nuevo modelo de suscripción y la Biblioteca de Facturación de Google Play 5.0
![Kate Qonversion Author](https://framerusercontent.com/images/22TVhXbeNHHY5fcrTOyur7zw.webp)
Kate
May 25, 2022
Durante la conferencia anual I/O, Google presentó su nueva versión principal de la Biblioteca de Facturación de Google Play. Además de las clásicas descontinuaciones y eliminaciones de métodos, también ofrecieron abundante información sobre la nueva arquitectura de las suscripciones. Esta última tiene como objetivo simplificar la forma de crear, gestionar y vender las compras dentro de la app. En este artículo, exploraré las actualizaciones de la Biblioteca de Facturación de Google Play 5.0 y profundizaré en las más interesantes.
![Resumen del nuevo modelo de suscripción y la Biblioteca](https://framerusercontent.com/images/q0ydnf29EyKr8Gq1HPkeEvulxM.jpg)
El nuevo modelo de suscripción
La compra de nuevas suscripciones
Y a propósito del código, en la Biblioteca de Facturación de Google Play 5.0, la clase SkuDetails
ha quedado obsoleta, así como cualquier otra entidad o método que contenga Sku
en su nombre. Ahora, hay que considerar el uso de ProductDetails
para ese fin. Los detalles del producto incluyen información sobre una suscripción. Por ejemplo, sus planes básicos y sus ofertas.
Antes, solicitabas detalles de la suscripción como los que se muestran a continuación:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Copy
Ahora, deberías hacer lo siguiente:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }
Copy
Y, para lanzar el flujo de compra, usabas las siguientes construcciones:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
Mientras que, ahora, deberían parecerse a lo siguiente:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Copy
También puedes echar un vistazo a los ejemplos de migración en la guía de migración oficial de Google. Eso sí, ten en cuenta que hay algunas erratas en sus ejemplos, pero se han corregido aquí.
Veamos los cambios.
Como he mencionado, ahora tienes que utilizar ProductDetails
para solicitar los detalles de la suscripción y el flujo de compra. Además, deberás proporcionar un offerToken
a los parámetros del flujo de facturación, ya que cada ProductDetails
puede contener varias ofertas. Ten en cuenta que la selección de detalles de la oferta (productDetails.subscriptionOfferDetails)
siempre incluye detalles del plan básico (si existe algún plan básico), por lo que incluso si tu suscripción contiene solo un plan básico sin ofertas, seguirá teniendo un offerToken
para la compra.
Puedes observar que el nuevo flujo de compra acepta múltiples ProductDetails
en vez de un SkuDetails
como en la versión anterior. No obstante, si proporcionas más de un ProductDetails
, el flujo terminará con un error. La guía oficial de migración da el ejemplo erróneo sobre el uso de los métodos setProductDetails
y setOfferToken
justo en la clase BillingFlowParams.Builder
, pero solo está disponible el método setProductDetailsParamsList
para estos fines. Parece como si, recientemente, Google hubiera decidido pasar de los detalles de producto únicos a los múltiples. Esto muestra una visión de futuro en la que la facturación admitirá varias compras de suscripción diferentes al mismo tiempo.
El resto del flujo (es decir, el procesamiento de la compra) sigue siendo el mismo que en la Biblioteca de Facturación de Google Play 4.0.
Compatibilidad retroactiva de las suscripciones
Bueno, hasta ahora, todo suena bien, pero ¿qué pasa si no quieres migrar ahora mismo? Google se ha encargado de ello.
A pesar de que Google Play Console ya funciona únicamente con el nuevo modelo de suscripción, todas las suscripciones antiguas se convierten al nuevo formato automáticamente. Por lo tanto, se conserva su retrocompatibilidad con versiones anteriores. Esto quiere decir que verás tus suscripciones en el nuevo formato en Google Console, pero podrás seguir trabajando con ellas de la misma forma en la que lo hacías antes en tu app.
De igual manera, también podrás observar que todas las suscripciones antiguas pasan a ser de solo lectura tras la migración. Por ello, Google te advierte de que la edición inhabilitará la compatibilidad con la API de InAppProducts de esa suscripción.
Es posible que utilices esta API en tu backend para obtener algunos detalles del producto, así que ten cuidado. Y es que, después de hacer editable la suscripción, surgirán errores (como se muestra a continuación) de esa API si intentas obtener información de la suscripción que se ha convertido. Lo mismo ocurrirá con todas las nuevas suscripciones creadas después del 11 de mayo.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}
Copy
Así pues, si utilizas la API de InAppProducts, considera la posibilidad de actualizarla antes de crear nuevas suscripciones o editar las antiguas.
Mientras navegas por la nueva interfaz de suscripciones en Google Play Console, encontrarás etiquetas «retrocompatible» cerca de los planes básicos y las ofertas de las suscripciones. Esto implica que si compras esas suscripciones utilizando SkuDetails
compatibles (como se hace en la Biblioteca de Facturación de Google Play 4.0), comprarás exactamente esos planes básicos u ofertas compatibles. Si solo hay un plan básico compatible, sin ninguna oferta que también lo sea, se comprará ese plan básico. Si hay tanto un plan básico como una oferta compatibles que estén disponibles, en ese caso, si la oferta se puede aplicar al usuario actual, se comprará. Si no, solo se comprará el plan básico. Si quieres, puedes elegir otro plan básico/oferta como retrocompatible con versiones anteriores.
Nota: esta retrocompatibilidad hace referencia a la Biblioteca de Facturación de Google Play, pero no a la API de InAppProducts. Como se ha mencionado anteriormente, si empiezas a utilizar las nuevas funciones (por ejemplo, varios planes básicos u ofertas para una suscripción) o, simplemente, la conviertes de solo lectura a editable, esa suscripción puede seguir siendo retrocompatible para una app, pero no para la API.
Otras actualizaciones
Ha habido varias actualizaciones menores en la Biblioteca de Facturación de Google Play 5.0 que vale la pena mencionar, aunque sea brevemente.
Se ha eliminado el método obsoleto
queryPurchases
de la Biblioteca de Facturación de Google Play 4.0.Ya no hay solicitudes sincronizadas, solo
queryPurchasesAsync
.launchPriceChangeFlow
ha quedado obsoleto: el nuevo flujo de cambio de precios recomendado requiere la confirmación de los clientes a través de la página de suscripciones de Google Play, por lo que se deben utilizar enlaces profundos para navegar por allí en lugar de recurrir al método BillingClient.Se ha añadido el método
setIsOfferPersonalized
para indicar un precio personalizado para los clientes de la Unión Europea siguiendo la Directiva de Derechos del Consumidor. Esta opción añade una línea en la parte inferior de la pantalla de compra de Facturación de Google en la que se indica que el precio se ha personalizado.
El nuevo modelo de suscripción y Qonversion
Mientras trabajamos en la asistencia de la Biblioteca de Facturación de Google Play 5.0, puedes seguir utilizando el SDK de Qonversion para tus compras dentro de la app. Ahora, utilizamos la Biblioteca de Facturación de Google Play 4.0, lo que significa que solo podemos gestionar aquellas suscripciones con planes básicos y ofertas retrocompatibles. Todavía es posible editar las propiedades que estaban disponibles en el modelo de suscripciones anterior, como el precio, el período de gracia, la duración de la prueba, etc., así como crear nuevas suscripciones. Solo hay que asegurarse de que, después, tengas al menos un plan básico retrocompatible y, si es necesario, una oferta retrocompatible. Además, sigue siendo necesario contar con un identificador de suscripción completo para configurar los productos en nuestro centro de productos, no identificadores de planes básicos u ofertas.
Si tienes cualquier consulta, no dudes en comunicárnosla. Estaremos encantados de ayudarte.
Enlaces de interés
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Read more
Read more
![Trash Panda App partners with Qonversion](https://framerusercontent.com/images/fIjbGE1BlBzu0OZK7vCihIvo.webp)
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
![StyleDNA with Qonversion](https://framerusercontent.com/images/0CYKPTzYfOn6vdokDrwSoFR4c.webp)
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
![WWDC 24 updates](https://framerusercontent.com/images/OFmq7UmE6o7QKdnnbRBNKtgo.png)
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024
![Parenting by Iben Sandahl uses Qonversion](https://framerusercontent.com/images/qJ2twjlmMxXqQ2MggeZqrVbB580.webp)
How A/B Testing with Qonversion Helped Iben Sandahl’s Parenting App Double Their Sales
Jun 13, 2024
Jun 13, 2024
![Trash Panda App partners with Qonversion](https://framerusercontent.com/images/fIjbGE1BlBzu0OZK7vCihIvo.webp)
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
![StyleDNA with Qonversion](https://framerusercontent.com/images/0CYKPTzYfOn6vdokDrwSoFR4c.webp)
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
![WWDC 24 updates](https://framerusercontent.com/images/OFmq7UmE6o7QKdnnbRBNKtgo.png)
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024