Please enable JavaScript to view this site.

Altova MobileTogether Designer

The core procedure of an in-app process is the transaction that carries out the actual purchase. It is implemented via the Purchase action, and it works as follows:

 

1.A Purchase action sends a purchase request from the app to the app store. The request contains (i) the name of the product to be purchased, and (ii) details of the user account to be used for the transaction (see screenshot below).

MTDInAPBuyButtonPurchaseAction

2.The app store responds with a summary of the product's key data and asks for confirmation of the purchase. The end user on the client device confirms the purchase.

3.The app store carries out the transaction and sends data about the transaction to the app. This data about the purchase is stored in the $MT_IN_APP_PURCHASE page source, inside a Purchase element (see screenshot below).

MTDInAPPgSrcPurchaseData

4.Once the purchase data has been received in the design, the actions of the OnPurchaseUpdated event are triggered. These are actions that you define. Typically, you would carry out the following steps:

 

i.Check the response code that the app store sends about the success/failure of the purchase request. You can retrieve the response code by using the function mt-last-in-app-purchase-response-code(). If the purchase request was successful, the function will return 0. Other return codes vary across platforms. (See the topic Other Operations for additional diagnostic functions, such as to check whether the user canceled the purchase.)

ii.If needed, save the purchase state of the product outside the $MT_IN_APP_PURCHASE page source (either in $PERSISTENT, some other page source, or an external file). You might want to do this if you want to keep, for some particular reason, a separate history of purchase activity.

iii.Activate the purchased product in the app. After checking the purchase state, subscription validity, possible cancellation, etc, of the purchase, you will need to activate the product accordingly.

iv.Acknowledge the purchase (via the Acknowledge Purchase action). You, as the designer, must trigger the Acknowledge Purchase action in order to finalize the purchase so that the vendor of the app (which could be you or some other entity) receives payment. Note that acknowledgment may be one of two types: (i) for subscriptions and non-consumable products, and (ii) for consumable products. For details, see the Acknowledge Purchase action and Example Project: The OnPurchaseUpdated Event. You should acknowledge the purchase after you have activated the product (see previous step); this would ensure that the end user receives the use of the purchase before any data related to the purchase is possibly modified.

 

Once a purchase has been acknowledged, the in-app purchase will be complete. Afterwards, you can query purchases and display information about purchases by using the Query Purchases or Restore Purchases actions. In the case of consumables that have been purchased for Windows devices, you can also use the Get/Report Consumable action to query how many credit units are still available (balance) and how many have been consumed (fulfilled).

 

© 2015-2021 Altova GmbH