-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restorePurchases returns unexpected transactionIdentifier #991
Comments
👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out! |
Hi! Thank you for raising this issue. We may need to escalate this further. Could you share the debug logs that reproduce this issue? |
Hi @WesleyClarkRC, thanks for getting back to me. Here are the Debug logs:
|
Hi @TobiDevloft, I apologize for the delay. Thank you for the debug logs. This difference in what is returned is actually a result of whether the transaction ID is returned from the device or through our API. From the device, it will be the one provided by the store, while through our API, it will be the hashed version of that. |
I'm facing the same problem here. Any plan to add a field in the api that match the transactionId in the SDK ? |
Describe the bug
When purchasing a package (consumable product), I'm storing the returned productIdentifier, purchaseDate and transactionIdentifier in my DB. I now want to implement restore logic using restorePurchases the following way:
const { nonSubscriptionTransactions } = await Purchases.restorePurchases()
My goal is to compare the restored transactions to the ones in my DB. However, the
transactionId
differs in the restored transactions from the original transaction.E.g., when the original transaction for
purchasePackage
looks like this:The corresponding restored transaction looks like this:
I could just link these transactions using the timestamp, but that does not seem like a clean approach. Am I misunderstanding something here?
I also noticed that the returned properties do not match the
PurchasesStoreTransaction
interface like specified, but that seems to be another issue.Thanks for your help!
The text was updated successfully, but these errors were encountered: