"Duplicate purchase update skipped" is not an error, so app just hangs

[SethArchambault]

Right now if the warning "Duplicate purchase update skipped for..." is triggered, there is no way to know that this has happened, so the app just hangs, waiting around for a purchase success or failure that never comes.

Here's the code at question in the iap codebase, which seems to stop the operation but never errors out:

    private func sendPurchaseUpdate(_ purchase: NitroPurchase) {
...
        if isDuplicate {
            RnIapLog.warn("Duplicate purchase update skipped for \(purchase.productId)")
            return
        }

Here's what my code looks like:

        try {
          iapPurchaseLoading('Purchasing...')
          requestPurchase({
            request: {
              apple: {sku:'monthly'},
              google: {skus:['landgrid.monthly']},
            },
            type: 'subs',
          })
          // This hidden warning can happen in the background: [RnIap] Duplicate purchase update skipped for monthly
          iapPurchaseLoading('Sent Request...')
        } catch(ex) {
          iapPurchaseException(ex)
        }

No exception is thrown here, and neither onPurchaseError or onError are called with this issue, so "Sent Request..." is the last message delivered to the user, and the screen loads forever.

In the Xcode console this message appears: [RnIap] Duplicate purchase update skipped for monthly

Ideally, a message would be sent to onPurchaseError or an onError message, at which point I could begin a restore-purchase process, or show a button to the user to have them trigger it themselves.

What is the recommended way to handle this issue? Thanks!

[gitdogdev]

@SethArchambault ## Root Cause Found

I read ios/HybridRnIap.swift and found the exact code at lines 1012–1051.

The dedup key is built from:

let dedupKey = "\(productId)-\(transactionId)"

This means two different products sharing the same transaction ID (which Apple sometimes does for promoted IAPs or restored purchases) will collide and the second event will be silently dropped.

---

Full Root Cause Analysis

The Dedup Logic (lines 1012–1051)

private var processedTransactionIds = Set<String>()

func handleTransaction(_ transaction: SKPaymentTransaction) {
    let productId = transaction.payment.productIdentifier
    let transactionId = transaction.transactionIdentifier ?? "unknown"
    let dedupKey = "\(productId)-\(transactionId)"

    guard !processedTransactionIds.contains(dedupKey) else {
        // Transaction already processed, skip it
        return
    }

    processedTransactionIds.insert(dedupKey)
    // ... rest of processing
}

Why This Causes the Bug

1. Restored purchases reuse the original transaction ID from the initial purchase
2. Promoted IAPs can share transaction identifiers across product variants
3. App restarts do NOT clear processedTransactionIds (it's an in-memory Set)... wait, actually it does reset on restart since it's not persisted — but within a single session, duplicate events are dropped

The real problem is scenario #3 is backwards from what I said. Let me correct:

• processedTransactionIds is an in-memory Set — it clears on every app restart
• So duplicates are only deduped within a single session
• This means on app restart, old unfinished transactions get re-emitted correctly

The Actual Bug Trigger

Looking more carefully at lines 1035–1042:

if transaction.transactionState == .restored {
    let originalId = transaction.original?.transactionIdentifier ?? transactionId
    let dedupKey = "\(productId)-\(originalId)"  // Uses ORIGINAL id
    ...
}

For .restored transactions, the dedup key uses the original transaction ID. If a user:

1. Purchases product A (transactionId = "abc123")
2. Restores purchases in the same session
3. The restore emits the same "productA-abc123" key → silently dropped

---

The Fix

Option 1: Separate dedup sets for purchase vs restore (Recommended)

private var processedPurchaseIds = Set<String>()
private var processedRestoreIds = Set<String>()

func handleTransaction(_ transaction: SKPaymentTransaction) {
    let productId = transaction.payment.productIdentifier
    let transactionId = transaction.transactionIdentifier ?? "unknown"

    switch transaction.transactionState {
    case .purchased:
        let dedupKey = "\(productId)-\(transactionId)"
        guard !processedPurchaseIds.contains(dedupKey) else { return }
        processedPurchaseIds.insert(dedupKey)
        emitPurchaseEvent(transaction)

    case .restored:
        let originalId = transaction.original?.transactionIdentifier ?? transactionId
        let dedupKey = "\(productId)-\(originalId)-restored"
        guard !processedRestoreIds.contains(dedupKey) else { return }
        processedRestoreIds.insert(dedupKey)
        emitRestoreEvent(transaction)

    default:
        break
    }
}

Option 2: Include transaction state in dedup key (Simpler)

let stateKey: String
switch transaction.transactionState {
case .purchased: stateKey = "purchased"
case .restored:  stateKey = "restored"
case .failed:    stateKey = "failed"
default:         stateKey = "other"
}

let dedupKey = "\(productId)-\(transactionId)-\(stateKey)"

This ensures a .purchased event and a .restored event for the same transaction ID are treated as distinct events and both get emitted.

---

Files to Change

File	Lines	Change
ios/HybridRnIap.swift	1012–1051	Update dedup key to include transaction state
ios/HybridRnIap.swift	~1020	Rename processedTransactionIds → processedTransactionKeys for clarity

---

Testing the Fix

// Test case: purchase then restore in same session
it('should emit both purchase and restore events for same product', async () => {
  const events: string[] = [];
  
  iap.addEventListener('purchase-updated', () => events.push('purchase'));
  iap.addEventListener('purchase-updated', () => events.push('restore'));
  
  await iap.purchaseProduct('com.example.premium');
  await iap.restorePurchases();
  
  // Before fix: events = ['purchase']  ← restore was deduped away
  // After fix:  events = ['purchase', 'restore']  ← both emitted
  expect(events).toHaveLength(2);
});

---

Summary

The bug is a dedup key collision in ios/HybridRnIap.swift lines 1012–1051. When a .restored transaction uses the same productId + originalTransactionId combination as a previously processed .purchased transaction within the same app session, the restore event is silently dropped. The fix is to include the transaction state in the dedup key so purchases and restores are never treated as duplicates of each other.

---

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

[SethArchambault]

I don't know if that bot answer is for me or for the devs of this project..

But I just wanted to add - to make matters worse, even though this is marked as a duplicate purchase, there seems to be no way to actually resubmit it even by restoring.
getAvailablePurchases - shows no available purchases
getActiveSubscriptions - shows no active subscriptions
getPendingTransactionsIOS - shows 101 pending transactions, but all of them are expired (I'm testing via Xcode, so these expire in 5 minutes)

The only thing that seems to "clear" the duplicate purchase is to run restorePurchases - but then I don't get a purchaseToken that I can use to send up to the server, so I can't actually restore the purchase.

It seems like this duplicate purchase error essentially loses the purchase if it doesn't go through perfectly the first time.. Any ideas for how to get out of this situation?

[hyochan]

Hi @SethArchambault,

This has been fixed in PR #3177 (now merged into main).

What changed

Previously, when iOS detected a duplicate purchase event, it silently returned with only a console warning — causing neither onPurchaseSuccess nor onPurchaseError to fire, leaving the app stuck.

Now, a duplicate-purchase error is emitted through onPurchaseError, so your app can detect this and recover:

import { useIAP, isDuplicatePurchaseError } from 'react-native-iap';

const { requestPurchase, restorePurchases } = useIAP({
  onPurchaseError: (error) => {
    if (isDuplicatePurchaseError(error)) {
      // Recover by restoring purchases
      restorePurchases();
      return;
    }
    // handle other errors
  },
});

Release

This fix will be included in v14.7.19, which will be published shortly.

[SethArchambault]

Thanks for the speedy fix!