Google Play Billing Library es lo primero que aparece en el radar de cualquiera que quiera ganar dinero con una app de Android, y conviene decirlo claro desde ya. No basta con colocar un botón de pago y esperar a que la magia ocurra. Esta herramienta oficial gestiona todo el entramado de las ventas digitales, desde un sencillo objeto consumible hasta suscripciones mensuales bastante complejas, manteniendo la experiencia limpia para quien compra.
Para que funcione de verdad hace falta algo más que cuatro líneas de código en el cliente. Se necesita un sistema coordinado entre la app y el backend, capaz de comprobar que el dinero ha llegado antes de entregar nada. Ese es el verdadero punto delicado de toda la integración.
Configuración inicial y conexión con Google Play
Antes de tocar el código toca dejar todo listo en la Play Console: definir los productos, fijar los precios y asegurarse de que la infraestructura de Google sabe qué se vende. Saltarse esta fase suele acabar en errores frustrantes en la primera transacción. Después llega el momento de añadir las dependencias en el archivo build.gradle, y quien trabaja con Kotlin tiene la suerte del módulo KTX, que mantiene el código mucho más limpio y evita la maraña de callbacks.
El núcleo de todo es el BillingClient, el puente entre la aplicación y los servicios de Google. Lo ideal es inicializar una sola instancia para que las notificaciones de compra no se dupliquen. Conviene activar la conexión cuando la app pasa a primer plano, apoyándose en los ActivityLifecycleCallbacks, y configurar un PurchasesUpdatedListener durante la construcción del cliente. Desde la versión 8.0.0 existe enableAutoServiceReconnection(), que restablece el vínculo de forma automática y reduce muchísimo los errores SERVICE_DISCONNECTED.
Link affiliatoMostrar productos, validar pagos y probar todo
Una vez conectados, queryProductDetailsAsync trae la información localizada de los productos, y aquí va un aviso: nada de cachear esos datos, porque un objeto obsoleto puede reventar el proceso de pago. La pantalla se abre con launchBillingFlow(). En la Unión Europea hay que vigilar setIsOfferPersonalized(), ya que la normativa obliga a avisar si el precio se ha ajustado por decisiones automatizadas. Para frenar el fraude ayuda mucho adjuntar el obfuscatedAccountId.
Detectar el pago es solo el principio. Lo seguro es enviar el token a un servidor propio que consulte la API de Google Play Developer. Los productos consumibles piden consumeAsync(), mientras que los no consumibles y las suscripciones necesitan acknowledgePurchase() en un plazo de tres días, o Google devuelve el dinero. Y ojo con las compras en estado PENDING, típicas del pago en efectivo: el beneficio no se entrega hasta que pasa a PURCHASED, por eso hay que llamar a enablePendingPurchases().
Para no saturar la API conviene usar las notificaciones RTDN mediante Google Cloud Pub/Sub, decodificando la información en Base64 y revisando el linkedPurchaseToken para evitar suscripciones duplicadas. Y antes de publicar, la app Play Billing Lab permite simular fallos de red y denegaciones de pago. Eso sí, las etiquetas como enableBillingOverridesTesting del AndroidManifest.xml deben desaparecer antes de subir la versión final a producción.
Fuente
Imagen: androidayuda.com
Link affiliato