Android purchases not being reported by success handler or listeners

[404-html]

Some purchases not being reported by success handler or listeners.
Same problem as on previous repo: hyochan/react-native-iap#3150 (reported by @renatomserra).

Unfortunately the issue is back again.

react-native-iap: 15.2.0
react-native: 0.81.5

For now I noticed that on Android only.

[gitdogbot]

@404-html

Correction: The earlier answer was inaccurate. The simple listenersAttached flag diagnosis does not match the code.

I checked HybridRnIap.kt in both current main and the react-native-iap-15.2.0 tag. endConnection() already resets listenersAttached = false, so adding that line is not the fix for the missing Android purchase callbacks.

The report is still valid, but the root cause is elsewhere. Later logs in this thread pointed to an Android ITEM_ALREADY_OWNED edge case: when Play Billing returned already-owned immediately from launchBillingFlow, the implementation needed to query current owned purchases for the in-flight SKU/type and republish matching purchases through the normal success/update listener path. That path was addressed in #189 and released in the follow-up versions noted by the maintainer.

If this still reproduces after the released fix, the next useful data is Android logcat around OpenIapModule / HybridRnIap, the purchase payload, and getAvailablePurchases() immediately after the failed flow.

---

🤖 Generated by gitdog.hyo.dev · Have more questions? Tag @gitdog and let me know!

[hyochan]

Thanks for the report. I checked both the current main code and the react-native-iap-15.2.0 tag.

The listenersAttached explanation in the gitdog comment above does not match the code: HybridRnIap.endConnection() already resets listenersAttached = false in 15.2.0, and current main still does. So adding that line is not the fix here.

There has been a related Android Billing reliability fix since 15.2.0: #159 made Play Billing callback bridges single-resume guarded and was released in react-native-iap@15.3.1 / openiap-google@2.2.1. Please try react-native-iap@15.3.1 first.

If this still reproduces on 15.3.1, please share:

• Whether this is in-app or subs
• The requestPurchase payload shape you pass
• React Native logs around initConnection, requestPurchase, purchaseUpdatedListener, and purchaseErrorListener
• Android logcat lines for HybridRnIap / OpenIapModule
• What getAvailablePurchases() returns immediately after the failed/missing callback

With those logs we can tell whether the purchase update callback is not arriving from Play Billing, arrives before JS listener registration, is dropped during conversion/validation, or is related to the already-fixed callback race.

[404-html]

Thank you @hyochan.
I updated to 15.3.1 and the issue is still there, I observed it so far twice.

I only sell subs.

The requestPurchase payload shape I pass:

await requestPurchase({
    request: {
        apple: { sku: plan.productId },
        google: {
            skus: [plan.productId],
            subscriptionOffers: plan.offerToken
                ? [{ sku: plan.productId, offerToken: plan.offerToken }]
                : undefined,
        },
    },
    type: 'subs',
});

The logs for the case where purchase was not captured:

{"code":"user-cancelled","message":"User cancelled the operation"}
{"code":"user-cancelled","message":"User cancelled the operation"}
{"code":"user-cancelled","message":"User cancelled the operation"}
{"code":"already-owned","message":"Item is already owned"}
{"code":"already-owned","message":"Item is already owned"}

I will add more logging, but meanwhile - any idea what can be the issue?

[hyochan]

Thanks for the follow-up. I checked the 15.3.1 report and the new already-owned logs point to a different gap than the earlier listener-state theory.

Root cause: when Google Play Billing returns ITEM_ALREADY_OWNED immediately from launchBillingFlow, the Play flavor only forwarded the already-owned error to purchase error listeners and completed the request with an empty purchase list. It did not immediately query the currently owned purchases for the requested SKU and re-publish a matching purchase to purchaseUpdatedListener / onPurchaseSuccess. That means a real owned subscription could be visible to Play Billing but still not be delivered through the success path after this edge case.

Fix is up in #189. The PR now handles that immediate launchBillingFlow result by querying Play Billing owned purchases for the in-flight SKU/type, then emits matching purchases through the normal purchase update listeners. If no matching owned purchase is found, it preserves the existing already-owned error behavior. This does not add a local purchase cache; it asks Play Billing for current ownership at the point of recovery.

Verified with:

• ./gradlew :openiap:testPlayDebugUnitTest --tests dev.hyo.openiap.QueryPurchasesRaceTest
• ./gradlew :openiap:compilePlayDebugKotlin :openiap:compileHorizonDebugKotlin

After this lands and is released, please try the next react-native-iap version and check whether the repeated already-owned cases now arrive in onPurchaseSuccess / purchaseUpdatedListener.

[huynhhq]

I have same issue here

[hyochan]

Update: this has been released.

The #189 fix for the Android ITEM_ALREADY_OWNED recovery path is now available in:

• react-native-iap@15.3.3
• openiap-google@2.2.2
• expo-iap@4.3.2
• flutter_inapp_purchase@9.3.3
• kmp-iap@2.3.2
• godot-iap@2.3.2
• OpenIap.Maui@1.1.5

Release note: https://www.openiap.dev/docs/updates/releases#android-already-owned-recovery-hotfix-2026-06-23

For React Native, please update to react-native-iap@15.3.3 and re-test the subscription flow that produced repeated already-owned errors. The fix does not add a local purchase ownership cache; when Play returns ITEM_ALREADY_OWNED immediately from launchBillingFlow, Android queries Play Billing for the currently owned purchases matching the requested SKU/type and republishes matching purchases through the normal success/update listener path.

If this still reproduces on 15.3.3, please share the new Android logcat lines around OpenIapModule / HybridRnIap, plus what getAvailablePurchases() returns immediately after the failed flow.