In the session on StoreKit 2 (which looks amazing!), the presenter says:
In fact, if your app is running when a purchase is made on another device, you'll be notified about the new transaction.
This seems to mean that when an app uses the listener API to be notified of transactions, it will get transactions that happened on other devices.
My app offers purchases across other platforms in addition to iOS, and when a purchase happens we register it with our own account system. If a user has the app running on both their iPad and iPhone and makes a purchase on the phone, if the iPad gets notified of it the same way it would of a purchase made on the iPad, both devices will try to report it to our system. This seems undesirable.
What's the recommended approach here? Should we just make sure our system will disregard duplicate transaction reports? Or is there a way to know whether a transaction originated on this device? I don't see a property on the transaction type that looks like it could accomplish this. Maybe the deviceVerification properties? But that's seems more like the new edition of transaction receipt verification - failing that check would presumably mean that the purchase is invalid, not that it didn't happen on this device...?
Assuming this is a non-consumable product, in the example you provided if a user purchases the product on their iPhone, the iPad will receive a Transaction with the same identifier as the one returned from purchase(options:) on the iPhone. In this case I would recommend relying on the transaction's unique id property to prevent recording a transaction in your system multiple times.
deviceVerification is meant to help you verify that the JWS was generated for the device StoreKit provided it on. It does not indicate anything about which device originated the purchase.
You might want to make use of some of the new App Store Server APIs for your system as well, which might provide more utility for your use case than just relying on the APIs provided in the StoreKit client framework.
