Auto-renewable subscription not working in production build!

Hello,


I have issues with my in app purchases which are auto-renewable subscriptions. In fact StoreKit doesn't give me any products, so everything else after that fails of course.


In sandbox mode everything works like a charm.


I searched Google for help, but all I have to do seems to be done already:


- Create a paid Applications contract

- Get in app purchase products approved


Do I have to somehow assign them to my app or binary or something (which I didn't becuas there's no option for that)?


Or is there a way to debug the production build in XCode with console?


Since the issue is urgent, I highly appreciate every help!!


Bye The_Unknown

In response to your finding, I think we should start with the fact - StoreKit is a set of API's for charging an iTunes User account for In-App Purchases. Once the charge has been billed to a customer credit card, the StoreKit API calls the updatedTransactions delegate method with the result of the transactions - purchased or failed. It's up to the application to act on the result - to provide content to the user or not.


If the StoreKit process successfully charges a user account, it's likely that the app is being passed the SKPaymentTransactionStatePurchased state at the updatedTransactions delegate method. You indicate that the app is not providing the associated products. Something is happening after the updatedTransactions delegate is entered to prevent the app from providing the content. You state that the things work in the Sandbox. I take it that App Review passed the app and now it's the production version which is failing. The first thing I'd check is to see if the app performs appStoreReceipt validation. If so, is the verifyReceipt URL for the sandbox server hardcoded into the app. This would explain why things work well in the sandbox and in App Review but fail in the production version. I'd review Tech Note 2413, iAP FAQ


<https://developer.apple.com/library/content/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-RECEIPTURL>


The app has to dynamically be able to attempt receipt validation with the production verifyReceipt server first. If the attempt results in status 21007, then test with the sandbox verifyReceipt server.


If this is not the reason, please provide more info about what happens after the updatedTransactions delegate method is entered and why the app may not provide content to the user.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

1) it can take 24-48 hours after approval for an IAP to appear.

2) there are a two differences between the two environments:

a) your contracts must be signed for a product to appear in production. A glitch in 'signing contracts' - it has been reported that the signing of a contract wasn't communicated through the system until the IAP was 'removed from sale' and then 'cleared for sale'

b) the website for uncoding the receipt changes. Rich explained 21007's. The idea is to test first in production and then test in sandbox so the final app is efficient.

@rich The problem cannot be validation since as I described in my first post, I don‘t even get the products from AppStore. @PBK I just put my iap out of sale and put them in sale again. Hoping that it works now :-( In Android my app was live in 15 minutes and everything working without ANY problems. Apple delayed me for 4 weeks now with this kind of issues!

Sorry that in my latter post there are now linebreaks. I was only posting with an iPhone, linebreaks aren‘t support with iPhone on the Apple forums.

And what might also be relevant: The IAP are not shown in the AppStore entry whereas those of other apps like deezer for example do. How can that be?

You worte:


"- Create a paid Applications contract

- Get in app purchase products approved"


For clarity....

1) Are your IAPs marked as approved on iTunesConnect? If so, how long ago were they approved?

2) Are your contracts all listed as signed on iTunes Connect?

1) Yes, they are approved ("Genehmigt" is approved in German). They're approved since 2018/03/07, 11 PM. (see https://drive.google.com/file/d/1fN5r2huI1sn2Xh7p-1tw9stUwgkGAwHc/view?usp=sharing)

2) I think so (see https://drive.google.com/file/d/1OrTPnuJOaJdT7BF9TBY2wJisyTGnFDVX/view?usp=sharing).

1) Yes, they are approved ("Genehmigt" is approved in German). They're approved since 2018/03/07, 11 PM

2) I think so


Unfortunately I cannot upload any images here so that you could evaluate my interpretation of the data yourself. So I uploaded the images to my Google drive and posted the links here, but now my post must be moderated (which last time took days...). So maybe you could send me a private message or give me your email so that I could send you the images? Basically my IAPs are marked "green" with the German word "Genehmigt" and in my contract section there's no blue button anymore (as there has been before I edited the data), but only gray ones, so I think, the contracts are OK.

> in my contract section there's no blue button anymore (as there has been before I edited the data)


So perhaps it is now just the 24-48 hour issue here - the time it takes for information (i.e. you signed the contracts) to flow to the Apple store.

I think I told it a little unclaer. The blue buttons were the last time visible weeks ago. But my IAPs have been approved on 2018/03/07 11pm. Is this also included by this 24-48h window?

If the contracts were approved (no blue buttons) before the IAP was approved then something is wrong. Use a DTS ticket to ask them to look into what is wrong.


But first check the following (since 48 hours have elapsed)

0) it works when run from an Xcode version that hits the sandbox environment

1) the IAPs are marked 'approved'

2) they are checked 'cleared for sale'

3) your attempt to purchase them fails when run from a device that deleted the old version of the app before loading a new version of the app from the App Store.

4) you aren't incorrectly relying on the sandbox website to verify the receipt

I met exact same issue in production build. Everything works fine in TestFlight and the IAP has been approved. Is there any update to this?

Hi,


Did you ever resolve this?


We also have the same issue: Auto renewable subscriptions working fine in sandbox/Testflight, but the product is not found in the production version. We also have non-consumable subscriptions (approved at the same time) and these have no issues.


All contracts are in effect (and signed long before IAP prodcuts were approved), IAP products are all showing as approved and cleared for sale.

Any help would be much appreciated!


Thanks

JME - Was your app just approved by App Review? If so, the following is from Tech Note 2413, In-App Purchase FAQ - may apply - otherwise please provide more details.


<https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-TROUBLESHOOTING-APP_REVIEW_HAS_RECENTLY_APPROVED_MY_APPLICATION__BUT_MY_IN_APP_PURCHASE_IDENTIFIERS_IN_THE_PRODUCTION_VERSION_OF_THE_APPLICATION_ARE_BEING_RETURNED_IN_THE_INVALIDPRODUCTIDENTIFIERS_ARRAY_>


App Review has recently approved my application, but my In-App Purchase identifiers in the production version of the application are being returned in the invalidProductIdentifiers array.


When an application is approved, the developer must also approve the application for release to the App Store. On approval, the application ID is activated to the App Store. The same activation is required for the in-app purchase identifiers and can only take place once the application is activated. In some cases, the activation of the In-App Purchase identifiers may lag up to 48 hours following the activation of the application.


If the developer does not approve the release of the production application to the App Store, then any new in-app purchase identifiers will not be activated. This is an issue when a developer wants to verify the application prior to activating it on the App Store. If the desire is to test the in-app purchase process for the new items, the application must be activated to the App Store. This is only an issue for new in-app purchase identifiers in a corresponding application submission. Once these in-app purchase identifiers have been activated, application updates to the submission will find that these in-app purchase identifiers are validated, even if the update is not activated.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Yes, the app was approved for review 3 weeks ago but we only released it today. This appears to be the issue and hopefully just waiting will resolve it.


Many thanks for your help!

The products are now showing 🙂 It took 30 hrs from intial release fo them being available in the production version even though they were visible in sandbox environment during this time.

Thanks again

Just wanted to share that I had this same issue and it took a little more than 24 hours for the issue to resolve itself. Seems strange so hopefully this is fixed by Apple soon.


Also talked to mutiple support people who did not know the real answer. One wanted me to use one of my Technical Support Incidents (TSI) to resolve the issue as they were certain my code was not correct, even after I explained that everything was working in TestFlight, was approved and all other, non-subscription In-App purchases were working just fine in production.


Hope this helps someone else knowing that the only solution for me was simply to wait.

I hope that this thread is still monitored, and that someone can provide a bit of guidance.

Our app uses two separate auto-renewable subscriptions (monthly/yearly). We have submitted it twice for review. Each time the app has failed to load the subscriptions successfully, and the review has failed. The app has worked consistently for months in Sandbox/TestFlight. Note: All of our contracts with Apple are in place and current.

We have an additional concern about submitting this app and subscriptions: Since our organization is still scaling up the back-end (mostly personnel, rather than servers), we cannot yet release the app to the general App Store public. Nevertheless, we need to have it reviewed as soon as possible so that any pending deficiencies won't delay our overall product release. Therefore, we set the Version Release option to “Manually release this version”.

One additional possible complication is that the app decrypts and verifies the receipt on-device, rather than through the App Store. We don't believe that will interfere with the process, but someone might have a better understanding.

Here is our dilemma: Our understanding of Rich Kubota's post (above) is that the subscriptions will not be available to the App Store until the app is released. However, the app cannot be reviewed and accepted unless the subscriptions are in place. So we have a couple questions:

(1) Is it even possible to submit both the app and the subscriptions concurrently?

(2) Does our decision to release the app manually render the review impossible?

If we cannot submit the app and subscriptions together for manual release, how can we have the app reviewed? In our case, the app will display only a blank screen until the subscriptions are activated. We would need to rearchitect the app significantly to submit a viable product without subscriptions.

At the moment, we can envision only the following scenario for approving our app:

(1) Create a free app version which loads and runs without IAP subscriptions.

(2) Submit this version for immediate release and wait for App Store approval.

(3) Once the version is approved, create new IAP subscriptions on App Store Connect.

(4) Wait 48 hours for the subscriptions to be available.

(5) Submit the real (original) app as an update to the App Store. Hopefully, this time the subscriptions will be available, the app will load and run, and the App Store will approve it.

Has anyone had a similar situation? Our concern here is that the free version of the app will be publicly available for several days.




Auto-renewable subscription not working in production build!
 
 
Q