## Zoho Billing - Product, solutions, integrations, support, and resources Index Access the complete documentation index at: https://www.zoho.com/ae/billing/llms.txt Use this file to discover all available documentation pages before proceeding. # Post-Implementation Checklist Start by working through each case in your sandbox environment. This checklist covers common integration scenarios for both iOS and Android; each section describes what to test and guides you through resolving any issues before going live. **Insight:** For platform-specific checks, see the post-implementation checklist for your channel; [iOS Post-Implementation Checklist](/ae/billing/help/omnichannel-subscription/ios/ios-sdk-checklist.html) or [Android Post-Implementation Checklist](/ae/billing/help/omnichannel-subscription/android/android-sdk-checklist.html). * * * ## Common Checks for iOS and Android ### Keep the SDK User State in Sync with Account Changes On each sign-in, initialize or reinitialize the SDK with the current user’s ID. On sign-out, clear or reset the SDK user information as required by the platform implementation. This prevents purchases and subscription entitlements from being associated with the wrong user, particularly when multiple users use the same device. ### Restore Purchases Not Acknowledged in Previous Sessions On app launch or sign-in, check for completed purchases that were not acknowledged in a previous session. If an unacknowledged purchase exists: 1. Call `restorePurchase()`. 2. Process the restored purchase. 3. Give the user access to their subscription. This ensures that users receive access to subscriptions they have already purchased. ### Show Only Active Plans from Zoho Billing Use `zsPlan.isActive` to filter the plans returned by the SDK and display only active plans. This prevents users from seeing plans that are no longer available in Zoho Billing. ### Display Store-Localised Prices in the App Display the price returned by the respective app store through the `productDetails` object. Store prices vary based on the user’s country, currency, and store configuration; hardcoding prices will cause mismatches for users in different regions. ### Recover Access for Already-Processed Purchases A purchase may already have been processed even if your app did not receive the final response. If you receive: * `purchaseAlreadyProcessed` on iOS * `PURCHASE_ALREADY_PROCESSED` on Android while creating a subscription: 1. Read the `subscription_id` from the error response. 2. Retrieve the corresponding subscription details from Zoho Billing. 3. Validate the purchase on your backend and map the entitlement to the correct user record. 4. If the subscription is already linked to a different account, do not provision the entitlement to the current user. Instead, either move the entitlement mapping to the correct account or stop provisioning until the entitlement is reassigned. 5. Give the user access to their subscription when the entitlement is correctly mapped. **Pro Tip:** Treat this as an access-recovery flow instead of restarting the purchase. After you retrieve the `subscription_id`, validate the subscription on your backend, map the entitlement to the correct user, and guide them to support only if the subscription details cannot be retrieved or reassigned. ### Include a Contact Support Option for Subscription Issues 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. **Pro Tip:** Display the _Contact Support_ as a clear call to action that prefills the available purchase, transaction, subscription, and account details. Where applicable, use `getPurchaseMetadataFromStore()` to include the store reference needed for investigation. ### Track SDK Errors with an External Analytics Tool The SDK does not provide built-in analytics for tracking errors. Use an external error-tracking or analytics solution to capture SDK errors. Track purchase failures and other integration issues so that they can be investigated after release. * * * ## Final Go-Live Checklist Before going live, test the complete subscription lifecycle end-to-end. ### Test Purchase and Subscription Activation **Scenario:** A new user purchases a subscription and should receive access immediately, with that access continuing through renewal. 1. Complete a test purchase. 2. Confirm that the purchase notification reaches your server. 3. Check that the subscription is created or updated in Zoho Billing with the correct plan and status. 4. Ensure that the user receives access to their subscription. 5. Test the renewal flow and confirm that access continues without interruption. ### Test Subscription Restore on a New or Reinstalled Device **Scenario:** A user reinstalls the app or moves to a new device and restores a previously purchased subscription. 1. Install the app on a fresh device or reinstallation using the same store account. 2. Log in with a user who has an existing subscription. 3. Restore the purchase. 4. Confirm that the correct subscription is identified in Zoho Billing. 5. Ensure that the user regains access without being prompted to purchase again. ### Test Account Isolation When Multiple Users Share a Device **Scenario:** Two users share a device. Subscriptions and purchase history must stay isolated between accounts. 1. Log in as User A and confirm the SDK is initialised with User A’s information. 2. Log out and clear the SDK user information. 3. Log in as User B on the same device. 4. Confirm the SDK reinitialises with User B’s details. 5. Ensure User B cannot access User A’s subscription, features, or purchase history. ### Test Subscriptions from Another Channel **Scenario:** A user with an existing subscription on one channel signs in on a different platform or attempts a plan change. 1. Check subscription visibility when a user has an existing subscription on another platform. 2. Test applicable web-to-mobile subscription change scenarios. 3. Test applicable mobile-to-mobile subscription change scenarios. 4. Ensure that purchases, plan changes, and subscription modifications from another platform are blocked when the subscription should remain on the original channel. ### Test Purchase Flows Across Different Subscription States **Scenario:** Users in different subscription states attempt to purchase or change a plan. Each case must route to the correct flow. 1. Complete a purchase as a user with no active subscription. 2. Change the plan for a user with an active store subscription. 3. Attempt a purchase for a user with an active subscription from another channel. 4. Simulate multiple active subscriptions and confirm that affected users are routed to support. ### Test Plan Upgrades, Holds, and Pause and Resume **Scenario:** A user upgrades a plan, places the subscription on hold, or resumes a subscription after a pause or temporary hold. 1. Test App Store plan upgrades from Settings and verify that the entitlement is updated correctly. 2. Test Play Store account hold and resume flows and confirm that the entitlements are restored correctly. 3. Verify that plan upgrades or subscription changes from another platform are blocked when the subscription should remain on the original channel. 4. Test subscription pause and resume flows and confirm that the subscription status updates correctly in Zoho Billing and the app. ### Test Store Notification Delivery and Sync **Scenario:** Subscription lifecycle events occur in the store and must be received, processed, and reflected accurately in Zoho Billing and the app. 1. Trigger a cancellation and expiration event in both stores. 2. Check that the subscription record in Zoho Billing is updated correctly. 3. Confirm that each notification reaches your server. 4. Ensure that the user’s access in the app reflects each change. 5. Verify that notifications from both stores are processed by the correct Zoho Billing organisation. **Warning:** Ensure the purchase, renewal, restore, account switching, cross-platform subscription, and store notification flows have been tested end-to-end before you go live. Untested flows can lead to incorrect subscription access or data sync issues.