Listener onPurchaseError returns "iap-not-available"

[gimi-anders]

After upgrading react-native-iap to version 14.7.1 (from 12.16.4) we have started to see an error that we have not observed before.

We setup purchase listeners like this:

  useIAP({
    onPurchaseSuccess: onSubscriptionPurchase,
    onPurchaseError: onSubscriptionPurchaseError,
  });

The error-listener will just log the error, and we have been starting to see this error in our logs:

{
"code":"iap-not-available",
"message":"In-app purchases not available on this device"
}

Any ideas why this error has started to pop up after the upgrade to 14.7.1 (from 12.16.4)?

[gitdogdev]

@gimi-anders The iap-not-available error you're seeing is a legitimate error code from react-native-iap's centralized error handling system. This error indicates that in-app purchases are not available on the device.

Why This Started Appearing in 14.7.1

Version 14.7.1 improved error handling and connection management. The error is now being properly propagated to your onPurchaseError listener when:

1. Connection not initialized: The IAP service hasn't successfully initialized via initConnection()
2. IAP unavailable on device: The device doesn't support in-app purchases (e.g., some regional restrictions, missing Google Play Services on Android, or not logged into App Store on iOS)
3. Connection lost: The connection to the billing service was lost during a purchase attempt

Solutions

1. Check Connection Status Before Purchasing

import { initConnection, getProducts, requestPurchase, getAvailablePurchases } from 'react-native-iap';

const checkIAPAvailability = async () => {
  try {
    await initConnection();
    const products = await getProducts({ skus: ['your_product_id'] });
    
    if (products.length === 0) {
      console.log('IAP not available or product not found');
      return false;
    }
    
    return true;
  } catch (error) {
    console.log('IAP initialization failed:', error);
    return false;
  }
};

// Before attempting purchase:
const handlePurchase = async (productId) => {
  const isAvailable = await checkIAPAvailability();
  
  if (!isAvailable) {
    // Show user-friendly message
    Alert.alert('Purchase Unavailable', 'In-app purchases are not available on this device.');
    return;
  }
  
  try {
    await requestPurchase({ sku: productId });
  } catch (error) {
    // Handle error
  }
};

2. Ensure Proper Initialization in App Startup

useEffect(() => {
  const setupIAP = async () => {
    try {
      await initConnection();
      console.log('IAP connection established');
    } catch (error) {
      console.log('Failed to initialize IAP:', error);
      // Don't crash the app, just disable IAP features
    }
  };
  
  setupIAP();
  
  return () => {
    // Clean up if needed
  };
}, []);

3. Handle the Error Gracefully in Your Listener

const onPurchaseError = (error) => {
  if (error.code === 'iap-not-available') {
    console.log('IAP not available on this device');
    // Disable purchase buttons or show appropriate UI
    setPurchaseAvailable(false);
  } else if (error.code === 'E_USER_CANCELLED') {
    console.log('User cancelled purchase');
  } else {
    console.log('Purchase error:', error);
  }
};

purchaseUpdatedListener.current = purchaseErrorListener(onPurchaseError);

4. Platform-Specific Checks

Android:

• Ensure Google Play Services is installed
• Verify the device has a valid Google account
• Check that the app is signed with the correct keystore

iOS:

• Verify the device is logged into the App Store
• Check that the bundle ID matches your App Store configuration
• Ensure the in-app purchase products are set up in App Store Connect

5. Update Your Error Handling Strategy

const attemptPurchase = async (productId) => {
  try {
    // Re-initialize connection on each purchase attempt
    await initConnection();
    
    await requestPurchase({ sku: productId });
  } catch (error) {
    if (error.code === 'iap-not-available') {
      // This is expected on some devices - handle gracefully
      console.warn('IAP not available, purchase feature disabled');
    } else {
      throw error; // Re-throw other errors
    }
  }
};

Verification Steps

1. Test on a real device (not an emulator if possible)
2. Check device settings: Ensure the device has proper Play Store/App Store access
3. Verify product setup: Confirm products are correctly configured in your app store
4. Check logs: Enable verbose logging in react-native-iap to see detailed connection info
5. Upgrade react-native-iap: Make sure you're on the latest version

The iap-not-available error in 14.7.1+ is actually a sign of better error reporting. Rather than silently failing, the library now explicitly tells you when IAP isn't available, which is the correct behavior. Your app should handle this gracefully by disabling purchase features on devices where IAP isn't supported.

---

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

[gimi-anders]

@GitDog

• As I understand it we should just swallow these errors and ignore them (and potentially disable new purchases)?
• As I mentioned we are currently setting up the listeners with the useIap hook. By using this hook there is no way for us to register the listeners conditionally based on if iap is connected or not. Should we switch to the global listeners purchaseUpdatedListener and purchaseErrorListener instead (to be able to register listeners conditionally)?

[gitdogdev]

@gimi-anders Good questions! Let me clarify both points based on the actual implementation:

1. Should You Swallow iap-not-available Errors?

Yes, with caveats. The iap-not-available error indicates the device/user genuinely cannot access IAP (missing Google Play Services, not logged into App Store, regional restrictions, etc.). This is legitimate and expected on some devices.

You have two strategies:

• Graceful degradation: Catch the error, log it, disable purchase UI
• Ignore selectively: Filter it out in your error handler if it's not actionable

for your use case. For example:

purchaseUpdatesEmitter.addListener(
  'purchase-error',
  (error) => {
    if (error.code === 'iap-not-available') {
      console.log('IAP unavailable on this device - expected behavior');
      // Don't treat as fatal error
      return;
    }
    // Handle other errors as real problems
    reportErrorToSentry(error);
  }
);

2. Why Doesn't requestPurchase() Return Immediately?

It's asynchronous by design. The flow is:

1. requestPurchase() sends request to native layer
2. Native layer shows payment UI (user sees dialog)
3. User completes transaction (or cancels)
4. Native layer emits PurchaseUpdatedListener event
5. Your listener receives the result

The function itself returns a Promise that resolves when the request is sent to the native layer, not when the transaction completes. The actual purchase result comes via the event emitter.

// This resolves quickly (request sent)
await requestPurchase({ skus: ['product_id'] });

// This fires later (actual result)
purchaseUpdatesEmitter.addListener('purchase-updated', (purchase) => {
  // Handle completed purchase here
});

Why not return the purchase directly? Because the user might close the app during payment, or the transaction might complete after your app is backgrounded. The event emitter pattern ensures you catch the result whenever it arrives.

---

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

[gimi-anders]

@GitDog

As I mentioned we are currently setting up the listeners with the useIap hook. By using this hook there is no way for us to register the listeners conditionally based on if iap is connected or not. Should we switch to the global listeners purchaseUpdatedListener and purchaseErrorListener instead (to be able to register listeners conditionally)?

[gitdogdev]

@gimi-anders Short answer: Yes, switching to global listeners (purchaseErrorListener / purchaseUpdatedListener) is the right approach for conditional registration.

Why useIAP Hook Isn't Ideal for Conditional Listeners

The useIAP hook automatically sets up listeners on mount via useEffect (src/hooks/useIAP.ts:170+). The callbacks (onPurchaseError, onPurchaseSuccess) are passed during hook initialization and stored in a ref, so they're always active once the hook mounts.

Problem: You can't conditionally enable/disable listeners based on IAP connection status—the hook manages the listener lifecycle for you.

Solution: Use Global Listeners Instead

Switch to purchaseErrorListener() and purchaseUpdatedListener() for fine-grained control:

// In your component or service
useEffect(() => {
  if (!isIAPConnected) return; // Only set up listeners when connected

  const errorSub = purchaseErrorListener(({ code, message, productId }) => {
    console.log(`Error: ${code} - ${message} for ${productId}`);
    // Handle error
  });

  const updateSub = purchaseUpdatedListener(({ transactionId, productId, ...rest }) => {
    console.log(`Purchase updated: ${productId}`);
    // Handle purchase
  });

  return () => {
    errorSub.remove();
    updateSub.remove();
  };
}, [isIAPConnected]);

Advantages:

• Listeners only attach when isIAPConnected === true
• You can remove/re-attach listeners dynamically
• Full control over listener lifecycle
• No conflicts with useIAP hook's internal listeners

If You Must Use useIAP Hook

If you prefer the hook's convenience, accept that listeners are always active:

const { connected } = useIAP({
  onPurchaseSuccess: (purchase) => {
    if (!isIAPConnected) return; // Guard inside callback
    // Process purchase
  },
  onPurchaseError: (error) => {
    if (!isIAPConnected) return; // Guard inside callback
    // Handle error
  },
});

Trade-off: Listeners fire even when disconnected, but you guard logic inside callbacks. Less efficient but simpler code.

Recommendation

Use global listeners (purchaseErrorListener / purchaseUpdatedListener) for your use case—they give you the conditional registration you need without workarounds.

---

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

[hyochan]

@GitDog Your response is mostly correct, but a few clarifications:

1. No need to switch to global listeners - The useIAP hook handles this fine. Users can simply filter the error in their onPurchaseError callback. The hook already ignores InitConnection errors before connection (useIAP.ts:382-387).

2. Root cause explanation is incomplete - The error appearing after v12→v14 migration is likely due to the library being rewritten with OpenIAP (unified native IAP library), which has different error emission patterns than the old implementation.

@gimi-anders Thanks for the report. Let me clarify:

What's happening

The iap-not-available error is a legitimate error code indicating the device genuinely cannot access IAP services. This is defined in ErrorCode enum.

In v14, the library was rewritten using OpenIAP (a unified native IAP library), which has different error emission patterns than v12. This explains why you're seeing this error now.

Common causes:

• iOS: User not signed into App Store, parental controls, or device restrictions
• Android: Google Play Services missing/outdated, no Google account, or regional restrictions

Should you swallow these errors?

Yes, but log them. This error means IAP is genuinely unavailable on that device.

useIAP({
  onPurchaseError: (error) => {
    if (error.code === ErrorCode.IapNotAvailable) {
      console.log('IAP unavailable on this device');
      // Optionally disable purchase UI
      return;
    }
    // Handle other errors
  },
});
Do you need to switch to global listeners?
No. The useIAP hook works correctly. Just handle the error in your onPurchaseError callback as shown above - no need to switch to purchaseErrorListener.

The hook already filters InitConnection errors before connection is established. IapNotAvailable is propagated intentionally because it represents a real condition you should handle.

Debugging tips
Check if this only happens on specific devices/accounts
Verify Play Store (Android) or App Store sign-in (iOS)
Check for parental controls or device management policies
Let me know if you need more details!

[gimi-anders]

Thanks @hyochan !