How to implement in-app purchases with Google Play Billing

Android apps in Australia can earn revenue from consumables, unlockable features and subscriptions through Google Play Billing. The Android client runs the checkout and reports purchase updates, while a secure backend confirms what each customer paid for. Treating both sides as one dependable workflow prevents free entitlements, duplicate grants and broken restores.

A reliable first release publishes one product to a closed test track, handles every purchase state and makes restoration automatic. It should cope with patchy mobile connections, show prices in Australian dollars and give customers an easy route to support when a payment or entitlement goes wrong.

Prepare the Play Console catalogue

Create the app record in Google Play Console, complete the app details and establish a merchant and payments profile. Add each product with a stable identifier that your app and server share. Descriptive names help in the catalogue, but the identifier is the contract between the client, Play and your backend.

Choose a product type before writing code. A consumable can be bought repeatedly and should be removed from the customer’s library after use. A non-consumable is a permanent unlock, while a subscription renews until it is cancelled or expires. Products that sell the same feature at different prices work better as separate identifiers than as hidden logic in one product.

Set the Australian price in AUD and review the Play Console tax settings before release. Google Play generally collects GST on eligible in-app digital purchases in Australia and includes the tax in the amount shown at checkout. Confirm the current tax treatment for your account, and ensure that product descriptions match what the app actually delivers under Australian Consumer Law.

Connect billing to the Android app

Use the current stable Google Play Billing Library and create one BillingClient for the app’s billing session. Query ProductDetails before displaying a price, because catalogue data can change between app versions. Cache only what you need, and refresh details when the customer returns to the purchase screen.

When the customer confirms a purchase, launch the Billing Flow with the selected offer and handle its result through the purchase listener. A successful purchase includes a token and purchase state; a payment can also be pending or cancelled. Show a clear pending message, prevent repeated taps and acknowledge every completed purchase within the required window.

On startup and after sign-in, query existing purchases and restore valid entitlements. Link purchases to a stable account identifier where the product supports account benefits, so a new phone can recover an unlock or subscription. Consumables still need an explicit server decision because Play may not treat them as restorable.

Secure purchases on your backend

Never grant an entitlement from the Android response alone. A modified app can forge client messages, so send the purchase token to your backend and verify it with Google’s Play Developer API. Use a server-side service account, keep credentials outside the repository and record the result in your purchase ledger.

Make verification idempotent by storing the purchase token under a unique constraint and returning the existing grant if the same token arrives twice. Process real-time developer notifications for refunds, revocations and other account changes. A refunded purchase should remove or suspend the associated benefit instead of leaving a stale unlock.

DigitalOcean is a practical host for this backend. Keep the purchase ledger in a database, place the application behind HTTPS and restrict direct database administration. If phpMyAdmin is available on the Droplet, protect it with strong access controls or an SSH tunnel rather than exposing it as the public purchase API.

If verification runs slowly and needs separate execution, this thread creation guidance shows a possible worker pattern. Keep the worker idempotent, and make the Google verification result authoritative before an entitlement is recorded or fulfilled.

Design clear purchase and recovery flows

Before confirmation, the customer should see exactly what is being bought and what happens next:

• Show the product name, key benefits and tax-inclusive AUD price.
• For subscriptions, state the billing period and renewal date.
• Explain that a pending payment may take time to resolve.
• Keep the primary action obvious and stop duplicate submissions.

Recovery should be equally deliberate:

• Restore prior purchases automatically after sign-in.
• Provide a visible Restore purchases control.
• Bind account-based benefits to a durable user ID.
• Handle refunded, voided and cancelled purchases without reissuing access.

Keep billing language plain and use Australian English without forced slang. Labels such as Buy now, Subscribe and Restore purchases are clearer than playful wording; a campaign can use a casual phrase such as arvo, but the checkout itself should stay exact. This reduces confusion and gives support staff fewer terms to interpret.

Test the full Australian purchase journey

Run the first release through internal and closed testing with licence testers. Exercise one-time purchases, consumables and subscriptions separately, using fresh accounts so restored entitlements do not hide a failed first purchase. Inspect Play Console test notifications and your own fulfilment logs together.

Test the unhappy paths that matter: decline a card, lose the connection during checkout, leave a purchase pending, reinstall the app and change the signed-in account. Also submit refunds and test duplicate server callbacks. Each run should end with one purchase record, one entitlement state and a clear support trail.

For Australian conditions, check that AUD totals and GST appear correctly, then test across the Android versions and screen sizes common to your audience. Include a regional connection profile and devices used from Brisbane, Sydney and Melbourne. Schedule release checks in Australian Eastern Time and retest around daylight-saving changes, since an incorrect renewal date can affect customer expectations.

Launch, monitor and keep improving

Roll out in stages and watch revenue, purchase completion, acknowledgement failures, refunds and backend errors together. A rise in checkout attempts with few completed purchases may indicate a catalogue or device problem, while successful Play purchases without backend grants point to validation or queue failures. Use aggregated logs and avoid recording sensitive payment data.

Keep the Billing Library and app-server contract updated, and retest when Play changes policy or a product is edited. Provide a support path that can locate an order by its token-derived record without asking for card details. Document who can reverse an entitlement and when restoration should occur.

Create the catalogue, connect BillingClient, validate one token on your server and complete a purchase from a closed-test account today. Once that path survives reinstall, refund and network-loss tests, add more products and widen the release with confidence.