Bug: Different Amazon Purchase UI and Infinite Loading State When Retrying a Purchase

Fire Devices & Appstore Q&A
2

Hi @Mohammed_Tariq

Welcome to Amazon Developer Community!

Thank you for the detailed report, screenshots, and thorough troubleshooting.

The two screens you’re seeing are actually two different subscription flows:

  1. First image - the standard IAP subscription purchase dialog (plan selection with “Purchase now”), triggered by PurchasingService.purchase(“SKU”).
  2. Second image - the Quick Subscribe flow (single “Subscribe now” button, auto-renew language). Note the “TEST” badge on the Eros Now logo - this confirms you’re testing a LAT (Live App Testing) build, not a production/sandbox build.

The switch between the two UIs after pressing Back, and the infinite loading, is a known characteristic of how the purchase flow behaves in the LAT environment - it does not reflect production behavior.

Answering your questions:

  1. Is this expected / a known issue?
    The infinite loading on re-initiating a purchase after Back is a known behavior specific to the LAT environment. In LAT, the purchase screen and Quick Subscribe flow can enter a delayed/stuck state after a cancelled attempt because the prior purchase session hasn’t fully cleared. This does not occur in production. (Reference: IAP LAT delayed purchase screen describes similar LAT-specific timing behavior.)

  2. Recommended workaround:

  • After a cancelled purchase (Back press), before re-initiating, call PurchasingService.getPurchaseUpdates(false) in your onResume() to reconcile any pending/incomplete purchase state.
  • If the UI is stuck in loading, press Home to return to the launcher, then re-open your app - this clears the stuck purchase session (as you already observed with the cache-clear).
  • Do NOT call purchase() again while a prior purchase session may still be pending - check getPurchaseUpdates() first.

  1. Is SDK 3.0.9 the recommended version?
    Yes, Appstore SDK 3.x is the current recommended version for production Fire TV IAP. 3.0.9 is fine. Confirm you’re on the latest 3.x patch.

  2. Why is onPurchaseResponse() not triggered during the infinite loading?
    The purchase UI runs outside your activity’s process (in the Appstore). When it hangs, the transaction never reaches a terminal state (SUCCESSFUL/FAILED/ALREADY_PURCHASED/INVALID_SKU), so no onPurchaseResponse() fires. The only lifecycle callback you’d see is onPause() (when the Appstore UI takes foreground). This is expected - the callback only fires when the Appstore returns a resolved result.

  3. How to detect a stuck/no-response purchase flow?
    There’s no direct “purchase timed out” callback. Recommended pattern:

  • In onResume() (when the user returns to your app after the purchase UI), call PurchasingService.getPurchaseUpdates(false). This reconciles any purchase that may have completed or is pending, even if onPurchaseResponse() didn’t fire.
  • Implement a client-side timeout: if onPurchaseResponse() doesn’t fire within N seconds of calling purchase(), treat it as incomplete and reconcile via getPurchaseUpdates() on next resume.
  • Always process receipts from getPurchaseUpdates() as the source of truth, not just onPurchaseResponse().

To confirm this is LAT-specific:
Could you test the same flow using App Tester (sandbox) or a production build (not the LAT build with the “TEST” badge)? If the infinite loading only reproduces on the LAT build, that confirms it’s an environment behavior rather than an SDK bug.

What would help us investigate:

  • Your app’s own logs around the purchase() call and any client-side SDK output (filter logcat by your own package name)
  • Your device DSN - so we can pull the Appstore-side purchase flow logs from our end to see why the UI hangs
  • Confirmation of whether this reproduces on a production build or only the LAT build

Warm Regards,
Ivy