Bug 27843 - [Unified API, iOS 7] In-App purchase failure: "Invalid Product ID" from SKProductsRequest
Summary: [Unified API, iOS 7] In-App purchase failure: "Invalid Product ID" from SKPro...
Status: RESOLVED DUPLICATE of bug 29180
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 8.6.0
Hardware: PC All
: --- major
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2015-03-10 18:15 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-04-21 03:35 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Packet captures from iOS 7 versus iOS 8 (18.38 KB, application/zip)
2015-03-16 15:44 UTC, Brendan Zagaeski (Xamarin Team, assistant)

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-03-10 18:15:45 UTC
[Unified API, iOS 7] In-App purchase failure: "Invalid Product ID" from SKProductRequest

We have received 2 reports today that In-App Purchases (via StoreKit) are failing specifically on iOS 7 after app migration to the Unified API. Unfortunately the failure does _not_ happen in the Sandbox environment. The failure results in an "Invalid Product ID" in the `ReceivedResponse` from `SKProductRequest`.

## Steps customers followed to reproduce

1. Migrate an existing app that uses In-App Purchases to the Unified API.

2. Publish the new Unified version of the app on the app store.

3. Install the app on an iOS 7 device from the app store.

4. Attempt to complete an In-App Purchase.

## Results

`SKProdutRequest` returns "Invalid Product ID" (in the `ReceivedResponse`) for each of the available In-App Purchase items.

## Expected results

All of the In-App Purchases _succeed_ on iOS 8 devices. All of the In-App Purchaes also _succeeded_ before the migration to the Unified API.

## Version information

(Not yet collected. I'll request some additional basic information from the users and update the bug accordingly.)
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-10 18:21:23 UTC
For thorough record-keeping, I'll note that one of the users who reported the problem posted a corresponding question on StackOverflow:

Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-10 19:31:58 UTC
To keep this bug report up-to-date with my searches here's an additional report from StackOverflow:


The latest update on that question (from today) is potentially interesting:

> We filed a support DTS incident three days ago, and have finally
> heard back. They agree with us that it appears to be an internal
> issue in the iTC web service that handles the InApp purchases. I'll
> keep this thread up to date.

And here's the corresponding forum thread from the same user:
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-16 15:44:58 UTC
Created attachment 10371 [details]
Packet captures from iOS 7 versus iOS 8

As a next incremental step in investigating this issue, I captured the TCP packets during a successful `SKProductRequest` (on iOS 8) versus a failed `SKProductRequest` (on iOS 7).

Unfortunately, because the request must be made over HTTPS (and must _not_ be made via an HTTPS proxy like Charles or Fiddler), there is no way to see the actual contents of the request.

## Observations

- It appears that the important requests are the ones to "itunes.apple.com" ("itunes-cdn.itunes-apple.com.akadns.net"). For example if I redirect traffic through an HTTPS proxy but _exclude_ traffic to "itunes.apple.com", then `SKProductRequest` seems to return the correct value.

- There is nothing obviously different about the request on iOS 7 vs. iOS 8: in both cases the app sends 1 encrypted packet to itunes.apple.com, and in both cases it receives 1 encrypted packet in reply. (See also the attached "good" and "bad" filtered packet captures (via `rvi` [1]).)

> [1] https://developer.apple.com/library/ios/qa/qa1176/_index.html#//apple_ref/doc/uid/DTS10001707-CH1-SECRVI

## Possible next step

Apple might be able to offer more insight into whether the problem is caused by the 1 encrypted packet the app is sending, and if so, what is wrong about that packet. Filing additional bugs with Apple [2] for each of the individual apps that is encountering this issue might help Apple investigate the issue more quickly.

> [2] https://developer.apple.com/bug-reporting/
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-16 15:59:46 UTC
## Steps followed to produce the packet captures from comment 5

1. Download CoinKeeper [1] from the app store onto an iOS 7 device and and iOS 8 device.
> [1] https://itunes.apple.com/en/app/coinkeeper-personal-finance/id849747345?l=en&mt=8

(From https://kb.xamarin.com/agent/case/131082.)

2. Enable `rvi` for the device, following the steps on [2].
> [2] https://developer.apple.com/library/ios/qa/qa1176/_index.html#//apple_ref/doc/uid/DTS10001707-CH1-SECRVI

3. Start capturing packets using `tcpdump` for the `rvi` interface on the Mac.

4. Start the app.

5. Swipe right-to-left 5 times (to get to the last screen showing "Limited time offer").


## Result on iOS 8

The "Premium version" modal window shows prices within each of the green buttons near the bottom of the window.

For example, "1 MONTH" shows "$1.99".

Tapping on any of the buttons shows a "Processing your payment" alert, and then prompts for iTunes Store login credentials.

## Result on iOS 7

The "Premium version" modal window does NOT show prices within any of the green buttons near the bottom of the window.

Tapping on any of the buttons shows an "Unable to process your payment" alert.
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-18 21:41:32 UTC
For anyone who is monitoring this bug and might be able to run some additional tests, I have only so far tested 2 out of 4 "interesting" configurations:

- iOS 7 on a 32-bit device (I tested on an iPhone 4, iOS 7.1.2)

- iOS 8 on a 64-bit device (I tested on an iPad Mini 2, iOS 8.0)

If anyone who is interested in this bug can try steps the steps from comment 6 [1], on either of the following 2 configurations, that _might_ reveal that the problem is actually due to 32-bit vs. 64-bit devices rather than iOS 7 vs. iOS 8:

- iOS 8 on a 32-bit device

- iOS 7 on a 64-bit device

I will also see if I can get access to either (or both) of these configurations and test them.

[1] When following the steps from comment 6, you can skip steps 2 and 3. Also note that none of these steps require having any payment information assigned to the Apple account. That is, none of these steps to test the problem require _completing_ a transaction.
Comment 8 Pavel Alekseev 2015-03-19 03:53:24 UTC

unfortunately we've encountered this bug on both 

iPhone 5s (iOS 7) and iPhone 4s (iOS8)
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-19 17:54:38 UTC
Hmm. The result on the iPhone 4S (iOS 8) is unexpected, since that would be an exception to the rule that the problem only happens on iOS 7.

I tested today on:

- iOS 7 on a 64-bit device (iPad Air (MD785LL/A), iOS 7.1.2). Result: FAILS.

- iOS 8 on a 64-bit device (iPhone 6 (MG552LL/A), iOS 8.0.2). Result: SUCCEEDS.

This doesn't absolutely _rule out_ that Xamarin could somehow be changing a value somewhere in the request that the app sends to the service, but it does suggest that the problem is not caused by a difference between 32-bit and 64-bit devices. And 32-bit vs. 64-bit problems seem like the most likely suspect for a problem caused by bugs in the Unified API vs. the Classic API.

One slightly "strange" experiment that _might_ be a way to work around this issue (if it is indeed a problem somehow related to the Xamarin bindings) would be to move the `SKProductRequest` code into a very small Objective-C iOS library, create an iOS binding project [1] for that library, and then call the library from the main Xamarin app. This is definitely a bit of a complicated approach, so it would need to be carefully tested in the "sandbox" environment before pushing it live on the store.

But that might reveal some other indirect clues to show how the problem is happening.

[1] http://developer.xamarin.com/guides/ios/advanced_topics/binding_objective-c/

If it would be helpful, I can help write the little Objective-C library and binding library, given the snippet from the original app where it calls `SKProductRequest`. Feel free to attach a snippet like that in a private comment on this bug report or in an email support case, if you think it might be helpful.
Comment 10 Pavel Alekseev 2015-03-20 03:40:28 UTC
Sorry, my mistake.

On iOS 8 with iPhone 4s it works fine.

We'll appreciate any help you can provide, since we don't have much experience with Objective-C :( W've send our code to support case :)
Comment 11 wilfred.willemink 2015-03-24 07:12:49 UTC
We are experiencing the same issue.

All SKProductsRequest calls with product identifiers fail on iOS7, but they succeed on iOS8.
Debug and AdHoc builds do work on iOS7, but the AppStore version does not work.
All product identifiers are returned as InvalidProducts.

As a workaround we ask our app users that report this issue to upgrade to iOS8, but that is not possible on all devices.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2015-04-21 03:35:40 UTC

*** This bug has been marked as a duplicate of bug 29180 ***