In order to take advantage of updates with Apple’s IAP system (as well as Amazon and Google) the current IAP behaviors are being deprecated, and replaced with new ones. These new behaviors are focused around a new system-created table called PurchaseTable. If a user has a game with a table already called PurchaseTable, they should rename it, save their game, and reload it so the system PurchaseTable can be created.
PurchaseTable has 5 columns: Id, Consumable, Name, Price, State. The users (you guys) need to fill in the Id and Consumable columns; the rest are filled in by the new IAP behaviors.
Definitions of what the 5 columns will hold:
- Id: the IAP provider item id.
- Consumable: flag that the item is consumable (can be bought multiple times). A consumable item can’t be repurchased until . the Consume Item behavior is run.
- Name: The localized name of the item.
- Price: The localized price of the item.
- State: The purchase state of the item. Can be “unpurchased”, “pending”, or “purchased”.
The new IAP behaviors are:
In App Purchase – Request Purchase Data: Sends a message to the IAP provider to get the localized name and price info for items. You pass in the start and end indexes of the PurchaseTable for the items you want to get (if the end index is -1, the last table row will be used). You also have to give it a callback attribute. This works the same as the network behaviors’ callback attribute: it is initialized to 0 when the behavior is run, and set to 1 when the data is received, and -1 if there was an error, such as no network connection.
Note that when displaying IAP item data, show the name and price as given in the table. This will be localized by the IAP provider to the appropriate format for the player.
In App Purchase – Restore Items: Sets the “state” column of any items purchased by the player, including consumable items that haven’t been consumed. This behavior should be called near the start of a game, after the purchase table has been initialized. There should also be a way for the player to trigger this behavior, in case the initial call couldn’t be made.
In App Purchase – Buy Item: Attempts to buy an item. The item state will be set to “pending” until the item is purchased or canceled. It’s important to understand that the purchase may not be completed immediately after, or even during the same session as when the request is made.
In App Purchase – Consume Item: Flags a consumable item as “unpurchased” so it can be purchased again. Until Consume Item is called, a consumable item may not be repurchased.
The basic steps:
Start by going into your Purchase Table and adding an Id (this will be the same as the SKU you put into iOS etc) as well as toggling whether or not you want this IAP to be consumable.
Next you need to create an Actor to be your purchase button. You need to use an “In App Purchase – Request Purchase Data” behavior somewhere in your actor. This behavior retrieves an item (or items) data from the store and fills in the Purchase Table with the data. Do not display purchase info for items until this behavior has been called. Tip: using a start index of 1 and end index of -1 guarantees that you will fill in all the data for the purchase table rows. This works because if the end index is negative we set it equal to the last row number in the purchase table.
After you’ve created an Id and have used the “In App Purchase – Request Purchase Data” behavior to fill in the rest of your table, you can create a purchase button. To do this simply create a rule that triggers when pressed and contains the “In App Purchase – Buy Item” behavior.
Once you have your button all sorted out you can add another rule to carry out what the users purchase should do (i.e give them some tokens/continues/coins or remove ads/unlock levels etc). Make this rule fire off when the text expression located in column 5 of PurchaseTable “is” purchased. This causes the rule to only activate on a successful in app purchase. Tip: it’s a good idea to have another table that stores the values that can be changed by your IAP’s and to save that table when a purchase is made (only the saving is shown in the image below not the table change). This will ensure that the users purchases will be saved and they won’t have to restore their purchases every time the game is closed etc.
If you have a consumable IAP then you will need to use the “In App Purchase – Consume Item” behavior after the item is bought. Using this behavior frees up the consumable IAP to be purchased again. Note: If a consumable IAP is bought, it will not be able to be purchased again until this behavior is used.
If a user buys a non-consumable item and reinstalls your game / has to switch to a new device having the ability to restore their purchases is important. That’s where the final behavior “In App Purchase – Restore Items” comes in. A simple way of implementing this would be to create a restore purchases button that contains a rule that fires off when pressed and calls the In App Purchase – Restore Items behavior.
There’s some more information to questions that have been asked located here: