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 AppModel.GetIaps() or the PlayerModel.GetIaps(). The difference is that the AppModel.GetIaps() function will return an IapCollection containing IapModels, while the PlayerModel.GetIaps() function will return a PlayerIapCollection containing PlayerIapModels. The 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 IapModel.

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.

From the 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.

Best Practices

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.