IAP not working correctly with Corona-2019.3528 and IOS 13

@Rob,

This problem seems to be the one I’ve been trying to solve for the past month. A growing number of my users have reported failed purchase and the only thing I could find is this truncated receipt that apparently started showing with iOS13.

I’ve tried working with the new plugin for apple store but there is no documentation on how to use it. specifically how to use the new methods around receipt validation. There should be some best practice on how to use it.

In addition, how should we tackle users with iOS12 and older when using the new plug-in 

We are looking into the issues.

Rob

Hey guys. Next daily build should not have receipts truncated, both in new plugin and core. New plugin is up now, but it would take couple hours for a new build to build. Also, added empty “transaction” table to IAP plugin.

Btw, about receipt validation. You can validate receipts locally without any 3rd party services using new plugin. Check decrypted receipt. It is checked locally on the device, and contains list of all purchases and subscriptions on the device, signed by Apple and verified with public key cryptography. I would suggest experimenting a little with it, and if you could share your experience, it would be great. Like, try to make some purchases and do

require("json").prettify(store.receiptDecrypted())

Cheers!

Vlad.

Vlad,

Great news- thank you.

Do I understand you correctly that it’s most likely safe to just continue using the built-in Apple IAP?

Thanks again!

OK. Here is the differene:

  1. Plugin: can be updated separately from the core. So plugin would have proper receipts with any version of Core. Also, plugin has some additional functionality, like using modern API to read receipt, as well as decode it, so you can locally verify purchase using public key cryptography, as well as read contents of receipts, which contains information about subscriptions and all purchases client made. Very useful.

  2. Core: apps are slightly smaller, because you don’t link the plugin. Also, what you get depends on version of the Corona you are using. Like, to get proper receipts in iOS13 SDK you would have to use 2019.3564+ or something.

They have pretty much identical code. Except that Core doesn’t have empty init event… It is really added only for compatibility with Android.

@vlads,

Great News. Thanks for your help in this!

Just two questions:

  1. If I remain with the core and build using 3564+, is it backwards compatible? meaning, do I cover iOS13 but also iOS12 and back?

  2. There are additional methods in the Plug-in version and its not clear what each does and how they integrate to the previous workflow we had in core. can someone provide the intended behavior end to end with the new plug-in?

  1. Yes. It is backward compatible.

  2. https://docs.coronalabs.com/plugin/apple-iap/ contains list of methods and basic information about them.

But you are right, Guide is needed for sure.

Meanwhile:

This methods are wrappers around appStoreReceiptURL

Method store.receiptRequest() is a wrapper around SKReceiptRefreshRequest.

After some consideration. I removed empty “transaction” table from the Init event. Sorry, it should not be there and breaking existing code.

For your convenience, here is example of decrypted receipt. I don’t think this format can change:

https://pastebin.com/embed_iframe/UQ18tuuJ

As you can see, it is a table. Here are some important bits:

decrypted = store.receiptDecrypted() decrypted.in\_app -- array containing all in apps

Example entry of decrypted.in_app:

{ "transaction\_id":"1000000454925773", // same as store listener transaction.identifier. Unique for each purchase, restore, or renewal "is\_in\_intro\_offer\_period":0, // 1 if subscription is in free trial still, 0 otherwise "product\_id":"com.coronalabs.IapTest.goodies", // same as transaction.productIdentifier "expires\_date":1539096727, // for subscriptions, this will be time subscription ends, same as purchase time for one timers "quantity":1, // ... "purchase\_date":1539096427, // UNIX time of when purchase was made "cancellation\_date":0, // time when user cancelled auto-renewing sub, 0 otherwise "original\_transaction\_id":"1000000454914195", // transaction.originalIdentifier, identifier of original purchase "original\_purchase\_date":1539095266, "web\_order\_line\_item\_id":"1000000040727298" // seems to be some apple internal stuff }

Fields in this structure are documented on Apple website: https://developer.apple.com/documentation/appstorereceipts

Hi @vlads,

I’ve tested the new core code and have a few notes:

  1. The app now receives full receipt in iOS13 - Great!

  2. Our previous receipt validation code via Apple server now fails with code [“21002”] = “The data in the receipt-data property was malformed.” perhaps there is a difference compared to previous receipt data, but I couldn’t identify what. Not sure how to proceed in this track yet.

I then tried to switch to the plug-in. Some notes:

  1. The plugin has some differences vs the core as already noted above (change in init, new event restoreCompleted, might be others)

  2. It’s not clear if I should use for each incoming transaction event store.receiptRequest(listener) or just try store.receiptDecrypted()

  3. In both cases I get All transactions history, where our previous validation received only the latest (we used exclude_old_transactions = true on the request post data).

  4. finishTransaction now fails when using the transaction object in two events: A. init B. restoreCompleted

  5. RestoreCompleted event seem to have no useful info. only type=‘restore’ and isError=‘false’

This is all I could find so far.

Thanks for investing the time on this.

Adi

  1. Yay!

  2. Our data before was formatted like “< 01234567 89abcdef … … … >”, base64 representation in <> quotes and groupped in 8 symbols. Plugin and core now return base64 representation without <> or spaces. I hope it’ll help. Showing what code you were using to verify purchases previously might help to understand what the issue is. For now I have no idea what’s going on.

  3. Yes. I has init which can be ignored, really, and done for just compatibility with android iap, and restoreCompleted. That’s it.

  4. In all my tests receipt is ready right after purchase.

  5. No idea what it means, because you’re talking about code I never saw… We just passing what Apple APIs give us. “Before” we ware using [SKPaymentTransaction transactionReceipt] which is long deprecated. This is one returned with lua’s transaction.receipt. We still returning it. New store.receipt* functions are all receipts.

  6. I changed plugins’ finish transaction so it doesn’t fail.

  7. It is by itself. Before it was like you hit store.restore() and never know when it is finished. Now you can see it in the event.

Also, here is some verification code I threw in. It seems to work fine. 100% local verification, no need for server:

local function verifyPurchase( identifier ) &nbsp;&nbsp;&nbsp; print("Verifying", identifier) &nbsp;&nbsp;&nbsp; local iaps = (store.receiptDecrypted() or {}).in\_app &nbsp;&nbsp;&nbsp; for i=1,#iaps do &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local iap = iaps[i] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if iap.original\_transaction\_id == identifier then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp; return false end store.init( "apple", function(event) &nbsp;&nbsp;&nbsp; local t = event.transaction &nbsp;&nbsp;&nbsp; if t then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if t.state == "restored" or t.state == "purchased" then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local verified = verifyPurchase(t.originalIdentifier or t.identifier) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print("Verified purchase", verified) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; native.showAlert("Purchase Verified", tostring(verified), {"OK"}) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp; store.finishTransaction( t ) end)

Here is my sample’s full code: https://pastebin.com/embed_iframe/SiBkHAnC
 

@vlads,

Thats exactly what I needed! previously we had to pre-process the receipt before sending it, now we can simply use it as is for validation. The core code now works for iOS13. I’ll also verify it formats the receipt the same way for earlier OS versions.

I will also try modifying our code to use the plug-in and see if we can safely switch.

Thanks again for your help!

Any news on this?

I just have updated my iPadPro to iOS 13.3 and now can not successfully test purchases. The game is not accepting the PW for my test account. Instead even with sandbox mode shown when clicking on a product I have to enter my real Apple ID to make a purchase work. I get a window for purchase successful BUT the code for the transaction listener to notice “purchased” state is not getting called!!!

What is happening here?

How can I fix this and what does it mean for old apps and games already in the store?

Are players updating to iOS 13.3 not able anymore to purchase something???

Hello. Can you replace main.lua with code I posted, then replace iap ids in it. I just tried on iOS 13.3, everything works

Thank you!

Can you please take a look at my other problem which probably is connected (?)

https://forums.coronalabs.com/topic/77024-problem-with-inapp-purchases-on-ios-133-ipadpro/?p=406303

I mean, it is your post… Lets  move conversation there.

@vlads, any new document updated for the new interface now?

I just got rejected because of this… (feeback from Apple Review)

We found that your in-app purchase products exhibited one or more bugs when reviewed on iPad running iOS 13.3.1 on Wi-Fi.

Specifically, we cannot complete the transaction of purchasing any in-app purchase products.

Next Steps

When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead.

I don’t have any idea what this means and how to solve it. Worked on the test device perfectly!

Can anybody help with this please?

d.mach-

GamingStudio17 and I both had similar trouble with App Store Review and got through by resubmitting with the following explanatory note:

"This app was built using Corona SDK. It appears that some developers are experiencing a problem where receipts are verified correctly in production, but fail in the sandbox. Could you please provide me with an error log so I can better understand what’s going wrong?"

The apps were then approved without comment, so I don’t really know what happened, but in terms of things to try, it’s pretty low-effort.

Thank you for your fast help! I must have over-read this one. Will do!