Store restore/purchase bug? with subscriptions

Solar2D Monetization (in-app purchases, ads, etc.)
#1

We’re encountering a rare issue with one of our apps concerning renewable subscriptions, The listener is triggered multiple times, as if we were restoring purchases (As expected) but the state is most of the time “purchased”, but never “restored”.

If we call store.restore() It will behave the expected way, products will have the “restored” state. The problem comes when you attempt to buy the same subscription and it has not expired, suspend and restore the app. The steps to reproduce this bug is the following:

  1. Start your app with no user logged in to the app store.

  2. Attempt to purchase a subscription

  3. Login popup will show, enter login credentials for test user.

  4. Accept the purchase, everything will be OK, listener fired a single time.

  5. Attempt to buy the same subscription again.

  6. It will say you already own this subscription, listener fired a single time, state is “purchased” again

  7. Close the alert, and suspend the App

  8. Reopen the app, the store listener will fire with previous subscription receipts for account (hundreds in my case)

  9. Expired receipts will have a “purchased” or “cancelled” state (95% purchased), no “restored”

We use the same test accounts over and over again, so we are receiving more than 100 receipts with the state property on “purchased” when this happens. All of the receipts are different and have different dates on them. I have yet to submit a bug report, so i would like to know if this is the expected behavior.

#2

Google Play’s IAP will never return an “restored” event. They only return “purchased”. You can look at the date of the purchase, or compare its receipt with one you have stored to verify it’s a restore. Or you can simply disable the paid for item and process the “purchased” event as new each time. Through for subscriptions, you probably want to check the date for sure.

Apple will send “restored” events. I’m unsure how Amazon deals with restores.

Rob

#3

@Rob, we’re using the Apple App Store (Forgot to mention that important detail) that’s why we think this might be a bug

#4

I don’t know about subscription restores. I’ve never set one up. Have you tried doing a Google search on it or see if Stack Overflow has comments from native developers on it?

#5

Yes, there seems to be this, from Apple developer documentation It says:

Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions.

And it does happen, but it also happens for all the old receipts.

#6

That makes sense. You should check the date to determine if the subscription has expired.

#7

Yes @Rob, thanks, we solved it that way. maybe this forum topic will help someone else in the future.

#8

Google Play’s IAP will never return an “restored” event. They only return “purchased”. You can look at the date of the purchase, or compare its receipt with one you have stored to verify it’s a restore. Or you can simply disable the paid for item and process the “purchased” event as new each time. Through for subscriptions, you probably want to check the date for sure.

Apple will send “restored” events. I’m unsure how Amazon deals with restores.

Rob

#9

@Rob, we’re using the Apple App Store (Forgot to mention that important detail) that’s why we think this might be a bug

#10

I don’t know about subscription restores. I’ve never set one up. Have you tried doing a Google search on it or see if Stack Overflow has comments from native developers on it?

#11

Yes, there seems to be this, from Apple developer documentation It says:

Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions.

And it does happen, but it also happens for all the old receipts.

#12

That makes sense. You should check the date to determine if the subscription has expired.

#13

Yes @Rob, thanks, we solved it that way. maybe this forum topic will help someone else in the future.