ios: onPurchaseSuccess triggered multiple times for a single purchase

[SethArchambault]

We just went live with an upgrade to react-native-iap version 14.7.20, and we've stated seeing that onPurchaseHandler is getting triggered multiple times for ios. Users seem to be paying and getting accounts correctly, but this means that our server is often getting with upwards of 10 verification requests for the same account (different apple transaction ids every time). They all land at the same time, so 10 accounts get created for the same user.

My current guess is that this could be happening for users with old storekit 1 transactions, which under the new system are found and resubmitted?

I will try to fix this in our app by having onPurchaseHandler add incoming purchases into a queue, and then we'll just run through that queue one at a time until something is successful, and then clear the queue to avoid any duplicates.

This is really unexpected, and it only seems to happen on ios - Android seems to be working fine.

Any idea if there are any simpler solutions to make sure onPurchaseSuccess only fires once?

[gitdogbot]

@SethArchambault Thanks for the detailed report. This is a real issue worth addressing in the library.

Root cause: StoreKit 2's Transaction.updates async sequence (which drives purchaseUpdatedListener) replays all unfinished/unverified transactions each time a connection is established — including old StoreKit 1 transactions that were never finished. Your guess is correct: users with old unfinished transactions will see multiple onPurchaseSuccess fires, each with a different transaction ID, all at once on app launch.

Looking at the code:

• packages/apple/Sources/Helpers/IapState.swift (lines 95–96): snapshotPurchaseUpdated() broadcasts every incoming transaction to all registered listeners with no deduplication guard at the emission layer.
• packages/apple/Sources/OpenIapStore.swift (line 117): onPurchaseSuccess?(purchase) is called for every event that arrives, with no transactionId deduplication before firing the callback.

What the library should do (actionable fix for maintainers):

• Track already-emitted transaction IDs in IapState and skip re-emitting the same transactionId within a session.
• Or, on initConnection, batch all pending transactions and emit them only after deduplication.

Immediate workaround for your app: Deduplicate by transactionId on your side before hitting your server:

// Track seen transaction IDs in a Set
const seenTransactionIds = new Set<string>();

purchaseUpdatedListener((purchase) => {
  const tid = purchase.transactionId; // or transactionReceipt / whatever your field is
  if (seenTransactionIds.has(tid)) return;
  seenTransactionIds.has(tid);
  seenTransactionIds.add(tid);
  // proceed with server verification
});

Also: always call finishTransaction after successful server verification. Unfinished transactions are the primary reason StoreKit replays them. If old transactions are never finished, they will keep reappearing on every app launch.

This is a library-level bug — the emission layer should deduplicate by transactionId before firing listeners, especially for the batch of pending transactions replayed at initConnection time. @hyochan would need to weigh in on the preferred fix location.

---

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

[hyochan]

Checked this against current main.

There is a valid shared Apple-core gap: requestPurchase and Transaction.updates could emit the same iOS transaction ID more than once during a single connection session because IapState did not track already-emitted purchase updates. PR #153 adds a session-scoped transaction ID guard in packages/apple and covers the reset/reconnect behavior with tests.

One important nuance: the original report mentions multiple different Apple transaction IDs. Those are distinct StoreKit transactions, often old unfinished transactions replayed by StoreKit. The library should not blindly collapse different transaction IDs because they may represent legitimate consumables, renewals, restores, or Ask to Buy completions. Apps still need to call finishTransaction after successful server verification and keep server-side purchase handling idempotent by Apple transaction/original transaction identifiers.

Also, the report references react-native-iap 14.7.20; this monorepo actively handles react-native-iap v15.0.0+. Please retest with the current v15 line once #153 lands.

[SethArchambault]

@hyochan Great! I was able to resolve the issue with the older unique transaction ids by validating the expiration time, so now the only issue I see are these duplicate transaction ids being sent up - it sounds like in the next version of react-native-iap, and following the above PR, that seems to be coming along.. Just so I can set my expectations correctly, are you expecting to launch this in the next week or do you think it may be longer than than?

Appreciate your quick work on this!

[hyochan]

@SethArchambault this is now released. PR #153 has been merged, and the duplicate iOS transaction update behavior is handled by default in the latest React Native release.

For duplicate iOS transaction updates, the default behavior now deduplicates StoreKit replay events by transaction ID during the current connection session, so repeated onPurchaseSuccess / purchase update callbacks for the same transaction ID should no longer be delivered by default.

If you do need to inspect raw StoreKit replay events for diagnostics or custom handling, you can opt out per listener:

purchaseUpdatedListener(onPurchase, {
  dedupeTransactionIOS: false,
});

// or with useIAP
useIAP({
  onPurchaseSuccess,
  purchaseUpdatedListenerOptions: {
    dedupeTransactionIOS: false,
  },
});

Release versions and package links are documented here: https://www.openiap.dev/docs/updates/releases#openiap-spec-2-0-2-purchase-update-replay-controls

The listener behavior docs are here: https://www.openiap.dev/docs/events/purchase-updated-listener