Android Post-Implementation Checklist

Use this checklist to verify your Zoho Billing Android SDK integration before going live. Complete the checks in a sandbox and verify that purchases, subscriptions, entitlements, and Play Store notifications are correctly synchronized with Zoho Billing.

Note:

Complete the Post-Implementation Checklist alongside this checklist. The common checks apply to both iOS and Android and must be verified before going live.

Note: Test the complete subscription lifecycle before going live, including purchase, renewal, restore, account switching, and Play Store notification flows.

Initialize and Manage the SDK Lifecycle

Initialize the SDK with the user’s information when the user logs in. When the SDK instance is no longer needed, call finish() to clear the SDK data.

Disable Debug Logs Before Going Live

Disable SDK debug logs before going live.

Use the required R8/ProGuard configuration for your release build. Ensure you don’t leave debug logging enabled in the production build.

Verify the Purchase Source

Before initiating a purchase, verify that the app was installed from the Google Play Store.

Check installerPackageName to determine the installation source.

Use only Play Store purchases for Android in-app purchase flows.

Verify the Purchase Association

Before initiating a purchase or plan change, call isStorePurchaseAssociatedWithCurrentUser().

If the Play Store purchase is not associated with the currently logged-in user, do not proceed with the purchase flow. Before displaying the purchase UI, determine whether the user is attempting an upgrade, downgrade, or restore.

Display Eligible Plans and Offers

Show Only Active Plans

Use zsPlan.isActive to display only active plans from Zoho Billing.

Hide Lower-Tier Plans When Downgrades Are Not Permitted

If downgrades are not allowed, consider hiding lower-tier plans from the plan-selection UI to avoid confusion.

Filter Plans by Region

If your app displays different plans for different regions, use the zsCustomFields array-list parameter to filter the plans returned by the SDK.

Check Introductory Offer Eligibility

Introductory offer eligibility is determined by Google Play. It is at the time of purchase for that plan, and it is the only source that holds this data. Introductory offers are not available to every user. Check eligibility against the store before showing the offer.

Use zsPlan.productDetails.subscriptionOfferDetails to check the offers eligible for the current user and plan. When introductory offers are configured, the SDK automatically applies the best eligible offer at purchase. Refer to Introductory Offers for details.

Handle Web or iOS to Android Subscription Changes

Allow only one active subscription per customer across all channels. If a customer already has an active subscription on the web or on another app store, block the Android purchase.

Play Store only knows about purchases made through Google Play. It has no visibility into web or iOS subscriptions, so neither the store nor the SDK can detect this kind of cross-channel duplicate on its own. Your app must determine the customer’s subscription state through your backend.

Before showing the Android purchase UI:

Have the mobile client request the customer’s current subscription status from your server.
Treat your server as the source of truth. It checks the customer’s subscriptions across all channels, querying the Zoho Billing APIs where needed, and returns the status to the client.
Based on that status:
- If there is no active subscription on any channel, allow the Android purchase to proceed.
- If there is an active subscription on another channel (web or iOS), block the Android purchase and guide the customer to manage the existing subscription on the channel where it was purchased.

Also confirm that the Google Play purchase belongs to the signed-in user by calling isStorePurchaseAssociatedWithCurrentUser() before proceeding.

Apply the Correct Subscription Rules

Before displaying the purchase UI, apply the following rules:

Subscription status	Action
No active subscription	Allow the purchase
Active Play Store subscription	Allow a plan change
Active non-Play Store subscription	Block the purchase
Multiple active subscriptions	Route the user to support

These checks help prevent duplicate or unsupported subscriptions.

Handle Renewal Payment Failures

When a renewal payment fails on the charging date, the subscription enters the grace period configured in Google Play Console.

Continue the user’s access to their subscription while it is in the grace period.

If a Google Play notification indicates that the subscription has been cancelled, remove the user’s access immediately.

Handle Restore and Support Flows

Restore Play Store Purchases Only

Restore a purchase only when:

The purchase is from the Play Store.
The user does not already have an active subscription.

This prevents a restore operation from conflicting with an existing active subscription.

Handle Already-Processed Purchases

If PURCHASE_ALREADY_PROCESSED is returned while creating a subscription:

Read the subscription_id from the error response.
Retrieve the subscription details from Zoho Billing.
Give the user access to their subscription.

Include Purchase Information in Support Requests

When a user contacts support about a Play Store purchase, include the information required to identify the purchase. Provide a Contact Support option in your app for subscription-related issues. Where possible, include the purchase, transaction, subscription, and end user’s account information required to investigate the issue. Provide a restore-purchase option from the support flow where appropriate.

Use getPurchaseMetadataFromStore() to retrieve the GPA ID and include it in the support request.

Was this document helpful?

Yes