Are the original_transaction_id fields in family sharing in-app purchase receipts populated with the ID of the original transaction (from the original purchaser), or does each family member get a new independent one? We're interested in supporting Family Sharing for our non-consumable in-app purchases, but since we also allow purchases to be activated on the web / other platforms, we're concerned that Family Sharing might enable somebody to create multiple accounts from a single purchase and use them independently on many more devices.
[tags:wwdc20-10661]
41 results found
Post
Replies
Boosts
Views
Activity
Hi. Has this changed since? Is the transaction order id shared between the purchaser and the family member now or is there a way to link them together?
At the moment we have an auto renewing subscription and we use the original_transaction_id as a marker in our database. If we turn on Family Sharing it was mentioned that each family member gets a transaction in the queue on their device. Will the original_transaction_id be the same for each user or will each user/Apple ID get their own unique receipt and set of transactions? Or is it simply a copy of the primary user?
Now this is live is there any tech guides on how this is implemented? Specifically around the identifications, is there any links back to the original purchase ID at all?
Now that the Family Sharing is up and running for renewable subscriptions, can someone confirm here what are the values received for the original_transaction_id field in receipt. Our assumption from the doc is that all customers should get the same original_transaction_id value as the original purchaser, while each transaction_id is unique. Others here are expecting different original_transaction_id for each customers. And the accepted answer is ?
when SKPaymentTransactionStatePurchased get SKPaymentTransaction value ：transaction.payment.applicationUsername is null base: Xcode Version 12.0 beta (12A6159) iOS 14.0 (18A5301v) print： (lldb) p transaction.payment.applicationUsername (NSString *) $1 = nil Will the official version of iOS 14 always be like this? please~
Any updates on that?? that's horrible
SKOverlay takes sometime to show up in the view because it has to fetch the app info from the server. So, is it possible to create SKOverlay beforehand and configure it to load the app info prior to calling present method? Because, with the current system, the user may leave the screen we want to show the SKOverlay before it shows up.
It's not currently possible to preload an SKOverlay. If a user switches to a new page before the overlay is presented, you can call SKOverlay.dismiss(in:) - https://developer.apple.com/documentation/storekit/skoverlay/3566701-dismiss to cancel the presentation and avoid the overlay being shown in an unexpected location.
The official version of iOS 14 , applicationUsername is null.
Any updates now? that's very horrible
Any updates on that?? that's horrible
Following-up on our original question, we were able to receive SKAdNetwork postbacks and wrote a blog post about our test setup. Check it out at singular.net/blog/ios14-skadnetwork-test-setup Hope it can help anyone!
Hi, We've recently registered our signing keys as an ad network. We want to verify our implementation of SkAdNetwork, and start receiving postbacks. However, for development purposes, waiting 24 hours for each postback experiment is inefficient and we'd love to progress in shorter cycles. What's the proposed way to test SkAdNetwork's implementation?
Same here, the lack of tools or proper documentation from Apple is pretty frustrating.