Hi, I'm reaching out to report a recurring issue with in-app purchases on iOS that seems to be related to Apple’s transaction handling — not to third-party libraries.
In my Flutter application, I use both StoreKit2 and StoreKit1 (for comparison) via different packages, including the official in_app_purchase package. However, in both cases, I’m experiencing unexpected reuse of transactionId and appTransactionId values, even when initiating fresh purchases with unique appAccountToken values.
Problem Summary:
Purchase Stream Returns Old Purchases
When calling buyNonConsumable() with a new product, the purchase stream still returns data for a previously purchased product, despite clearing all Sandbox transactions and using a new applicationUserName for each attempt.
Transaction IDs Reused Across Distinct Purchases
Even when generating a new UUID for appAccountToken on each purchase, the returned appTransactionId and transactionId are reused — this breaks our server-side logic, which expects these fields to uniquely identify purchases and users.
Example Logs:
// First purchase
{
"appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904",
"appTransactionId": "704464472748013865",
"transactionId": "2000000928154716"
}
// Second purchase (different user context)
{
"appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904",
"appTransactionId": "704464472748013865",
"transactionId": "2000000928429780"
}
Even when using a different productId, the appTransactionId stays the same. When using StoreKit1, the productId updates properly, but the transactionId still matches the previous one.
This behavior also affects App Store Server Notifications (V2): we have observed notifications tied to appAccountTokens from completely different user accounts (based on internal logs), sometimes delayed by days or weeks.
I’ve prepared a reproducible example using the official Flutter in_app_purchase sample with minimal changes — you can find it here:
Github gist
The code is almost identical to the package example. I only added UUID generation for applicationUserName in _getToken(). In the actual app (not in this example), I retrieve the token from an API.
Additional Observations from the Community:
We’ve also found similar issues reported in other frameworks and languages. For instance, a developer using react-native-iap observed that App Store Server Notifications in TestFlight were tied to previously deleted users, even after signing up with a new user account and generating a new appAccountToken. Details here:
User A deleted → User B signs up → receives upgrade event with User A’s token
Notification uses appAccountToken from old account, not the new one
This strengthens the suspicion that the issue may be related to how Apple associates transactions with Apple IDs in test environments.
Questions:
Is it expected for transactionId or appTransactionId to persist across purchases within the same Apple ID, even for different user contexts (e.g., separate logins in the same app)?
Is there any official recommendation for avoiding this kind of data reuse in Sandbox or TestFlight environments?
Should I expect appAccountToken in server notifications to always match the latest value provided during the purchase?
Thank you in advance for your assistance. I would appreciate any clarification or advice regarding this issue, as it impacts production logic that relies on these identifiers being unique and consistent.
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
Subscriptions
StoreKit Test
StoreKit
In-App Purchase