It is possible to support in-app purchases (IAPs) using IMVU credits. In order to set this up, you must first create a set of IAPs on the IMVU website, as detailed here. To initiate a purchase, you need to get the
IapModel for the purchase you want to make, and then call the
Purchase() function on that. This will initiate a callout to the IMVU website, very much like the connection process, where we confirm that the user actually wants to make this purchase. (If the user accepts the purchase then they are "authorizing" it.)
Once the user authorizes the transaction, the app will need to fulfill it, which is basically notifying IMVU that the purchased goods have been delivered. Any transaction that is authorized but not fulfilled within 13 days will be reversed. This is necessary in case a hiccup in the communication prevents the app from becoming aware of the transaction after the user has authorized it.
There are two ways to get at the
IapModels: through the
.GetIaps() or the
.GetIaps(). The difference is that the
.GetIaps() function will return an
IapModels, while the
.GetIaps() function will return a
PlayerIapModel has only two fields: whether the IAP is currently purchasable by this player, and how many times it's been purchased. You can then call
GetIap() on it to get the actual
Note that both of these calls can optionally take a
List<int> in order to specify a specific set of IAPs you're looking for by ID. You can get these IDs off the web page where you created the IAPs.
PlayerModel, you can also call
GetTransactions() in order to get a
TransactionCollection containing a set of
TransactionModels. This will include all of the purchases the user has ever attempted, including those that failed, were reversed or were not authorized.
1. Check for unfulfilled transactions
When your app opens, it should always get the list of the player's transactions and look for any that are in the
Authorized state. This is a transaction that the user has authorized, but has not yet been fulfilled. If a transaction is left in this state, it generally means there was some hiccup in the communication that prevented the app's servers from being informed of the transaction when it initially happened.
For any such transactions you find, you should ensure the user has been given the goods they purchased, then have your app's servers fulfill the transactions with IMVU. If they aren't fulfilled within 13 days, it's assumed your app will never fulfill them, and they're reversed.
2. Track the player's inventory on your servers
What the player has purchased and used should be tracked on your servers. If the player switches devices and loses their local storage, they should not lose their purchases.
3. Use the transaction list as the definitive source of truth
The transaction list is the definitive list of what the player has actually spent credits on. If that list conflicts with your records of the player's inventory, the transaction list should take precident.
4. Check for the availability of IAPs
If you fetch the list of IAPs through the
PlayerModel, there is a field called
isPurchasable which determines whether the IAP can currently be purchased by this player. The main reason this would be
false is if the player currently has an authorized but unfulfilled transaction for this IAP. If you are fulfilling transactions as soon as they occur, and checking for unfulfilled transactions at startup, then this is should almost never occur, but it's not practical to definitively prevent all corner cases, so it's good practice to check this boolean anyway. If it's false, then the UI should prevent the player from attempting to purchase this IAP again.