Amazon IAP v2 - transaction states

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

I have been working on migrating may Amazon IAP v1 to Amazon IAP v2. In this process, I’ve encountered a few questions. Could you please clarify my understanding of the transaction states for new Amazon IAP v2?

1. It appears as though transaction states in Amazon IAP v1 included only : “purchased”,  “failed”, “restored” and “revoked”. Correct?

2. Now for Amazon IAP v2, it has been explicitly stated that the “restored” transaction state is no longer used. But I haven’t seen any mention of the “revoked” state. Was that removed as well?

3. So now, are the only states available for Amazon IAP v2 “purchased”, “failed” and “cancelled”? If I understand correctly, in Amazon IAP v1, the “cancelled” state was not used. (“Transaction objects in the callback listener will never be of the state “cancelled”. Instead, .state will equal “failed” if the user canceled the transaction.”)

4. If these assumptions are correct, this would mean that when migrating from Amazon IAP v1 to v2, one should not just handle the removal of the “restored” state. But should also handle the removal of the “revoked” state and the addition of the “cancelled” state.  Correct?

5. Additionally, assuming the “revoked” state is no longer used in Amazon IAP v2. Does this mean that no store (iOS, Google Play, Amazon, or otherwise) API uses the “revoked” state any longer? 

6. It would be useful if there were some type of easy go-to resource that has a matrix of all the available transaction states for each of the stores. The current documentation is quite confusing because it requires searching through multiple store API’s (iOS v. Google v. Amazon) as well as multiple versions for an individual store (Amazon v1 v. Amazon v2). It’s difficult to know and understand which transaction states exist or not.

Thank you!

#2

Since there as no mention of “revoked”, I would say you need to still support it. I know with Google Play, they will issue refunds. I’m unsure on Amazon, but it doesn’t hurt to support it anyway.

Amazon with regard to “restored” was like Apple where “purchased” and “restored” were different transaction states. Google Play has never had a “restored” state. Instead, when you call store.restore() you get “purchased” transaction states and its up to you to look at the purchase date and see if it’s a new transaction or an old one, though it doesn’t really matter. If your app starts up assuming everything’s locked and you don’t have the settings saved (i.e someone deleted the app and reinstalled it, which is the only time you need to do a restore anyway), then handling a bunch of “purchased” is going to be the same as if they bought them new, just in rapid succession. You might want to check the date of the transactions and change the messaging to the user: “Welcome back” instead of a bunch of “Thanks for the purchase” dlalogs, if you’re showing them anway.

If you’re building a cross-platform solution, you should handle all of the possibilities. What I mean by this is if you plan to IAP with Apple’s iOS you are going to have to handle restored state. You will never get a revoked from them, but you will from Google.

Rob

#3

To my knowledge, no store uses “revoked” anymore. It was part of Amazon IAP v1, but clearly v1 will be unsupported soon.

As Rob mentioned, if you’re implementing IAP across all major platforms, you need to rig it up to work on each. We’ve taken reasonable steps to make IAP work similarly on all platforms, but the inherent differences between each store makes it impossible to accomplish a simple “load > purchase > done!” type of flow (believe me, I wish it was that simple).

Brent

#4

Since there as no mention of “revoked”, I would say you need to still support it. I know with Google Play, they will issue refunds. I’m unsure on Amazon, but it doesn’t hurt to support it anyway.

Amazon with regard to “restored” was like Apple where “purchased” and “restored” were different transaction states. Google Play has never had a “restored” state. Instead, when you call store.restore() you get “purchased” transaction states and its up to you to look at the purchase date and see if it’s a new transaction or an old one, though it doesn’t really matter. If your app starts up assuming everything’s locked and you don’t have the settings saved (i.e someone deleted the app and reinstalled it, which is the only time you need to do a restore anyway), then handling a bunch of “purchased” is going to be the same as if they bought them new, just in rapid succession. You might want to check the date of the transactions and change the messaging to the user: “Welcome back” instead of a bunch of “Thanks for the purchase” dlalogs, if you’re showing them anway.

If you’re building a cross-platform solution, you should handle all of the possibilities. What I mean by this is if you plan to IAP with Apple’s iOS you are going to have to handle restored state. You will never get a revoked from them, but you will from Google.

Rob

#5

To my knowledge, no store uses “revoked” anymore. It was part of Amazon IAP v1, but clearly v1 will be unsupported soon.

As Rob mentioned, if you’re implementing IAP across all major platforms, you need to rig it up to work on each. We’ve taken reasonable steps to make IAP work similarly on all platforms, but the inherent differences between each store makes it impossible to accomplish a simple “load > purchase > done!” type of flow (believe me, I wish it was that simple).

Brent