cancel
Showing results for 
Search instead for 
Did you mean: 

Why should I send an API request to Oculus when an IAP item is consumed?

Brainlogin
Protege
From the documents I understand I can have my players purchase consumables on Gear VR without having to go through the trouble of setting up my own trusted server just to use s2s REST requests to the Oculus server, without opening the Pandora's box of handling sensitive information such as access tokens, keeping them secured etc. Like I said, I can have the purchase done without all this hustle. But then it goes on to say that just to "consume an IAP item that a user has purchased" requires you to interact directly with Oculus server.

Example request:
$ curl -d "access_token=$USER_ACCESSTOKEN" -d "sku=$SKU" https://graph.oculus.com/$APPID/consume_entitlement

So my question is why would I go through all that trouble just to keep the number of my consumables updated on Oculus server? Isn't it okay just to have the user purchase them and then keep the consumption tracked from my code?

For example user buys 6 "power balls" for 6 euros. What's the benefit of consuming them on the server rather than just keeping the number tracked on the phone? Is this a required step serving some legal purpose? Or perhaps it's because the phone is vulnerable so a hacker could change the number of his power balls to have a million? (It wouldn't really bother me if there were a few instances like that) Or maybe it's not required, just an extra feature for those who want to synch the number of power balls for multi platform games or share with other players etc?
3 REPLIES 3

Brainlogin
Protege
Thanks @imperativity . In that case is my understanding correct that as long as you only sell durable IAP items, you don't need your own trusted server and S2S request, but as soon as you want to sell consumables, you need S2S. Meaning I should try to sell everything as durable if I want to avoid having to run a server.

Brainlogin
Protege
Thanks @imperativity , that answers my question. I thought S2S was imperative for IAP, the wording of the documents indeed confused me bit. Those are good news then.

Brainlogin
Protege
@imperativity
Related to this, why doesn't Oculus allow the same consumable item to be purchased any number of times? My users should be able to buy as much of the same consumable (eg. as much virtual money) as much they want. Couldn't Oculus just offer to register how many of a consumable item has been purchased by the user instead of blocking the item from purchase until it gets consumed?

For now, if I want to ensure continuous access to a virtual good, the only way as I see is to send a request to Oculus to consume the product right after purchase (so it reenables it for sale) while keeping a track of the actual consumption on client side.