Showing results for 
Search instead for 
Did you mean: 

How to reliably consume S2S IAP items from a user's inventory

Honored Guest


I think there's an oversight in the existing API for consumable inventory that I'd like to know the correct way of working around.

Let's say I have a feature where I'm awarding a player currency for purchasing a consumable item via in app purchases (like listed on this page

What I'm trying to do from our game's server, is consume the 100 coins consumable and credit the player with coins after it has been consumed. This workflow in itself is not too complicated, but the details around the transaction I'm unsure about.

I think with the naiive implementation of "consume the item via the api, and then credit the currency in the database" there's a risk of both consuming the item from meta's s2s API, and _not_ awarding the currency due to a database error or a server crash. The inverse is also true, where I could eagerly credit the currency, and roll back my transaction if the s2s consume query fails, because we might be forced to roll back the transaction if the server crashes during the request to the s2s API (even if that request is one that the meta server's considers successfully completed).

Usually, the workflow for this kind of thing would use transaction objects for the consumption of the item so that we could record that we were _about_ to consume the item, then if anything goes wrong, we could query the state of that transaction on the vendor API and mark it as finalized if it did in fact succeed but we never recorded the result. (the steam API InitTxn, QueryTxn and FinalizeTxn are an example of this kind of transaction workflow).

I think I could do this with the meta S2S API's by using a transaction recorded on our servers if:
1) I could consume an item by it's item ID instead of it's sku
2) I could check if we've consumed the item with the given item id

Also, I'm not sure what to do about chargebacks or other kinds of voided transactions for consumable items.



Hey Jake, 
have you been able to figure out a good flow?

@meta is reading these at all ? 

seems 99.99% of posts have no  answers.

Honored Guest

Hey! We ended up accepting the risk here that in a failure corner case, we would end up consuming the consumable and not creating a corresponding record. We create records locally when we go to consume the consumable, which leaves enough of a paper trail to handle any broken transactions on a case by case basis. It should be mentioned, as long as that gap from when you issue the request to consume the item and create the corresponding artifact on your system is as narrow as possible (and contains as little behaviour as possible) it should be an outside chance that it ever happens even with decent traffic on those endpoints. (we've never had it happen personally)

As for chargebacks and voided transactions, I think meta does their own auditing on their purchasing systems so in general you can assume that you don't need to handle those cases directly.