IAP - slow card responses and where to put iap.finish()

Setup: mobile game for android.

After reading extension-iap tutorial, api reference, google’s tutorial on billing, looking at extension-iap demo project and checking out different topic on this forum, I still have some questions about implementing IAP using extension-iap.

  1. Where to put iap-finish(transaction) and iap.acknowledge(transaction)? API reference states “The transaction.state field must equal iap.TRANS_STATE_PURCHASED.”. So if transaction.state is something else, I do not have to finish or acknowledge the transaction? And what is the difference between those two?
  2. Do I need to do anything special when the transaction.state is NOT PURCHASED, but something else?
  3. Dealing with slow card responses. How to correctly deal with slow card responses? When testing slow test card, I sometimes get the same error as described in this post., but since a succesful transaction will still finish with TRANS_STATE_PURCHASING, I can live with that. My game will give the user the bought product only when iap.TRANS_STATE_PURCHASINGmessage is fetched with iap-listener.
    But what happens if the user exits the game before that happens? Will calling iap.list() or setting iap.set_listener(iap_listener) check for unverified purchases? If not, is there a way to do that?
    Or will such transaction never be verified (and be refunded by google play after three days)…

From my experience, you should use iap.finish() when you got iap.TRANS_STATE_PURCHASED message in your iap listener and verified it with your server. But if you want to use iap.finish() you should disable auto-completion (this feature automatically finish transactions right when it’s purchased) at the IAP section of game.project file.

I think it depends but generally you can skip it

You shouldn’t worry about it because the payment will be refunded to that user card after a few days because your app hasn’t call iap.finish(), thus, when user close the app, the listener also released, nothing handled

1 Like

Check out the “Life of a purchase” document for Google Play Billing.

The lifecycle is:

  1. Show the user what they can buy.
  2. Launch the purchase flow for the user to accept the purchase.
  3. Verify the purchase on your server.
  4. Give content to the user.
  5. Acknowledge delivery of the content. For consumable products, consume the purchase so that the user can buy the item again.

As you can see from this flow you are meant to call iap.acknowledge() once you have given the content to the user. And then, if the product is consumable, you also consume the product, which you do by calling iap.finish().

Each of them has a specific meaning:

  • TRANS_STATE_FAILED - show an error to the user
  • TRANS_STATE_PURCHASED - deliver the item to the user (before optional server side verification etc)
  • TRANS_STATE_PURCHASING - show the user that the purchase is in progress
  • TRANS_STATE_RESTORED - you get this on iOS when restoring purchased products
  • TRANS_STATE_UNVERIFIED - the purchase is in an unspecified state

Ongoing purchases which have not failed or finished will be received again when you set the IAP listener function. This will be true until the purchase has failed or the purchase has completed and you have called iap.finish() etc