Objective
In-app purchase (In-app Purchase) is definitely a very important feature for developers, and it provides a convenient portal for users to pay for their purchases. Before the IAP, game operators usually charge by accessing Third-party payment portals. Previously done an Android mobile game server (asp.net), they use the payment method there are two kinds, one is access to Alipay interface, so that users can pay for the Polaris payment. Another is through the mobile phone operators to pay, first by the user to pay the operator, the operator through your registered server API told the user has paid. There is no need to worry about Third-party pay servers in Windows Phone 8, and Microsoft has provided us with a paid feature, the IAP that was previously mentioned, and the whole process of paying is by Microsoft's trading platform (Microsoft Commerce Platform) To provide support, through the Windows.ApplicationModel.Store namespace of the API can be very easy to implement the IAP function, eliminating a lot of access to Third-party pay interface debugging time. The following diagram describes the process for creating and purchasing virtual items.
A/b: developers register their own paid app and all virtual items information through Dev Center. If the product is to be downloaded from the server, then you need to provide this server yourself.
C/D: The developer pulls the virtual items registered in the store and displays them in the app, which the user clicks to buy.
E/F: Microsoft trading platform tells your app users to pay for success and get electronic receipts.
g/h: Download the virtual items from your server by using the receipt from the Microsoft trading platform as a voucher. and inform the trading platform that the product has been successfully distributed.
The whole process is very simple and clear, it should be noted that if your game is very lightweight, such as a stand-alone game, then the virtual goods do not need the support of the server, electronic receipts This step can be omitted. Large mobile games typically have back-end server support. E-Receipts provide a valid voucher for us to download the plugin from the server. Let's omit the two steps of registering the application and the virtual item first, do a simple client IAP example.
private async void LoadListingInformationAsync()
{
try
{
// Query the Windows Phone Store for the in-app products defined for the currently-running app.
var listingInformation = await CurrentApp.LoadListingInformationAsync();
foreach (var v in listingInformation.ProductListings)
{
Products.Add(new ProductViewModel() { Title = v.Value.Name, ProductId = v.Value.ProductId, ImageUri = v.Value.ImageUri });
}
}
catch
{
// An exception is expected to be raised by CurrentApp.LoadListingInformationAsync()
//when it is not called from an app installed from the Windows Phone Store.
}
}
The code above is an asynchronous collection of virtual items from the store that we've registered in advance. Currentapp is a very important class that contains all the main ways to manipulate virtual objects. Through the above method to obtain the information of the virtual items, we can do further processing of data, in the example of a ObservableCollection type of collection producets to save the data, and through the databinding to display it on the merchandise page, For users to choose to buy.
Private async void Purchaseproduct (string productId)
{
try
{
//Kick off purchase; don ' t ask for a receipt When it returns
await Currentapp.requestproductpurchaseasync (ProductId, false);
Now, give the user the goods they paid to
//(Dofulfillment is defined later)
//dofulfil Lment ();
}
catch (Exception ex)
{
//When the user does not complete the purchase (e.g. cancels or navigates back from the Purchase Page),
//An exception with a HRESULT of E_fail is expected.
}
}
See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/