HI Guys,
I have integrated the new Unity iAP (with the new iOS promotional iAP) and when i am using the link for testing:
(itms-services://?action=purchaseIntent&bundleId=XXXXX&productIdentifier=gYYY) it only works when the app is already opened in the background.
Looking at the logs. when the app is closed and i use the link, the app is opened, but it does not get in the ''ProcessPurchase" callback (but when the app is in the background it does get into this function).
Any ideas why?
As said in this comment [Solved] iOS: support for new promoted IAPs in iOS 11 - Unity Services - Unity Discussions u need init store as early as possible. But this is very inconvenient. Is there any way to change this?
If you arenât listening for purchases when the app starts, then you may miss purchases that are initiated outside the app (either from the App Store or through promo codes). It is also an Apple requirement.
As mentioned, the Purchasing system has to be initialized when the app starts for the promo purchases to work. However, if you are doing that and it still doesnât work, please let me know and weâll look into it.
Hi @ap-unity ,
We still donât see the purchase event (only in case the app is closed).
We are working on that issues for few days now and it seems that everything is ok from our side (and of course initializing the IAP is one of the first things we do)
Can you please take a look on it? we will be happy to supply more information if needed.
Thanks
@Bruder ,
Thanks for the extra details. We are looking into doing some more testing on this feature next week. I will update you when I have more information.
Hi @ap-unity ,
We just found out something interesting about this. when we turned off âLog In-App Purchase Events Automaticallyâ in our Facebook console, it started working. It seems that Facebook Unity SDK (10.7) somehow prevent the call to âProcessPurchaseâ callback.
I tested on other project with integrated Facebook SDK and have same issue with âturned on âLog In-App Purchase Events Automaticallyââ.
Hi everyone,
beside Facebook SDK, AdMob plugin with default settings also may be the reason of this behaviour.
Actually general the problem is that SKPaymentQueue will fire an event with promo IAP once as soon as it will have at least one observer. As some of analytics/ads plugins have feature of auto IAP reporting, they add their observers on app launch and tells SKPaymentQueue that game ready to handle events when itâs not.
Due to apple docs, event handler may store SKPayment for promo IAP and proceed it later when game will ready to handle it.
So for properly implementing this feature seems few changes require for Unity IAP:
@ap-unity , tell me plz if i have any mistakes in my description, and if we could wait for implementing features i suggest in anyway in near feature?
@pivnix ,
Your description of the problem is correct, however, your proposed solution may still run into this issue. It will always be a race for whoever gets to SKPaymentQueue first. We have no control over what AdMob or Facebook do in their SDK.
Currently, the only workaround is the one mentioned: Disable the âLog In-App Purchase Events Automaticallyâ feature in Facebook SDK or equivalent features in other SDKs.
The Facebook FAQ has details on how to disable this feature:
@ap-unity , thanks for answer
i understand that you have no control over any 3rd party plugins and SDKs that may be implemented, and impact that they can have on the project, but:
Due to iOS In-App purchase best practice, observers should be added on didFinishLaunchingWithOptions delegate, so if Unity IAP may have option to add itself observer on this point, race problem wonât be relevant as promo IAP callback doesnât call immediately after first observer added and invoking order of observers doesnât matter in this case.
But this scenario anyway require Deferring or Canceling a Transaction feature implemented, for querying stored promo IAP SKPayment later in app.
What do you say, @ap-unity ? Deferring or Canceling a Transaction is needed not only to resolve this issue, but for another use cases too. For example, we need to cancel a transaction if the user has already unlocked the product they are trying to buy
Hi, we have recently tried this feature and we canât make it work. We created special scene to initialize the iap and we are sure that there are no other plugin initializations. We get an error : [SKPaymentQueue]: Tried to send purchase intent: to delegate, delegate does not respond to method paymentQueue:shouldAddStorePayment:forProduct. However if we reload game quickly, we get our transaction. Can u advice anything?
It seems we are also having this same problem in an (unreleased) game of ours, though I havenât tested it much yet.
It would be very nice to get this initialization and purchase on iOS via promoted IAPâs 100% working in time before iOS 11 public release, as it offers potentially big ASO-possibilities - if it works reliably, which Apple will enforce or reject the app, probably.
Another question:
I am testing on an iOS 11 beta device building with Unity 5.6.1 and the latest version of Unity IAP. I am initialising the store in a method called during [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)] and am having the same issue. Only works if app is open in the background.
Not using Facebook or AdMob SDK, but I am using various Analytics providers and HeyZap + UnityAds + Vungle
Deleting all of our video providers fixed this issue, but thatâs far from ideal. Will follow up with HeyZap to see if they can toggle a switch for âLog In-App Purchase Events Automaticallyâ
Edit: Resolved as per HeyZap! docs
So any ideas or solutions for this issue?
Iâve also run into the error mentioned above when the game is not already running in the background and needs to be started to complete the App Store purchase (using Unity IAP 1.13.1):
(StoreKit)[729] : [SKPaymentQueue]: Tried to send purchase intent: gold_pack_3 to delegate, delegate does not respond to method paymentQueue:shouldAddStorePayment:forProduct
I suspect the issue here is that UnityIAP does not add the SKPaymentTransactionObserver until the product list has been received from Apple, hence there is no delegate present to respond to the purchase intent.
I reworked our boot flow to initialise UnityIAP first, before any other subsystem, but am still seeing several seconds (on an iPad mini) between requesting products and adding the SKPaymentTransactionObserver, as this logging shows:
2017-09-15 11:34:32.450091+0100 cccg[261:6154] UnityIAP:Requesting 13 products
2017-09-15 11:34:37.524536+0100 cccg[261:6154] UnityIAP:Received 13 products
2017-09-15 11:34:37.796610+0100 cccg[261:6154] UnityIAP:addTransactionObserver
With promoted IAPs, Apple passes the SKProduct and SKPayment info with the delegate shouldAddStorePayment. If the SKPaymentTransactionObserver is added as soon as UnityIAP is initialised rather than waiting for the product list to be retrieved then I expect the delegate would be found and the purchase flow could start?
Many thanks
Steve
You can expect an update for this issue soon (hopefully within a week or so)
Thatâs great. Thanks JeffD