These processes describe how purchasing and restoration are done when the content is not protected with built-in DRM.
Note: The in-app purchase API functions provide options that you can use to alter the details of how purchasing or restoration is handled with Nokia Store. The following are examples of possible scenarios, but for detailed information about all the possibilities, study the API reference.
The following diagram illustrates the purchasing process from the point of view of the application and Nokia Store. The diagram also shows the publisher's server, which the application can use as its own back end implementation to store and deliver the content to be purchased. The green color indicates the secure payment process that is executed by the in-app purchase API rather than the application.
Figure: Purchasing process with non DRM protected content
The purchasing process is as follows:
To be able to display the purchasable items to the end user, the application must know the IDs of the products that are available for purchase. You use Nokia Publish to identify in-app purchase items and get IDs for them.
The back end server provides the product IDs.
To get the product metadata to display in the UI, the application sends a request with all the item product IDs to Nokia Store.
Nokia Store returns the product metadata (name, price, and description) that matches the given product IDs.
The application displays the items to the end user, using the metadata received.
The end user selects which item they want to purchase, and presses a Buy button.
The application triggers a payment process using the in-app purchase API.
Nokia Store processes the payment, and completes the transaction. The process includes prompting the user for their Nokia account password, if the user is not yet signed in, and prompting for the confirmations needed.
The application retrieves the receipt data for the transaction from Nokia Store through the IAP service, and sends the receipt data to the back end server.
The back end server reads the receipt data, and sends it to Nokia Store for verification.
Nokia Store returns both the receipt, and a confirmation of whether or not the receipt (and consequently the purchase) is valid.
The back end server delivers the content or service. The end user can now access the purchased content or service in the application.
The following diagram illustrates the restoration process from the point of view of the application and Nokia Store. The diagram also shows the publisher's server, which the application can use as its own back end implementation to store and deliver the content, and to enforce access control. The green color indicates the secure payment process that is executed by the in-app purchase API rather than the application.
Note: You can design the restoration process for your application in a number of different ways. For example, in addition to displaying the purchasable new items (steps 1–2), you can provide a menu option to the user to check for any restorable items in Nokia Store. Or, on the catalog page where you list the purchasable items, you can display an 'Activate' option right away: the user can attempt a restoration first, which may then fail if the user is not entitled to restoring it.
It is the publisher's responsibility to make sure that the end user does not pay for an item if they are entitled to restore it free of charge. This can be verified, for example, based on the user’s account, device, or SIM card. You could design the process, for example, so that when the end user is attempting to purchase an item, after they have signed in the application silently checks if the user is actually entitled to restore the item. If yes, the application switches from a purchase process to a restoration process, starting from step 10 below.
The following steps describe one possible restoration process with non DRM protected content:
To be able to display the purchasable items to the end user, the application must know the IDs of the products that are available for purchase. You use Nokia Publish to identify in-app purchase items and get IDs for them.
The back end server provides the product IDs.
To get the product metadata to display in the UI, the application sends a request with all the item product IDs to Nokia Store.
Nokia Store returns the product metadata (name, price, and description) that matches the given product IDs.
The application displays the items to the end user, using the metadata received. In this scenario, the application also displays a UI option (or options) to the user for checking if there is any previously purchased content to restore.
The user selects this option, and the application sends a request to the back end server to find out which items the end user is entitled to restoring. This step includes first prompting the user for their Nokia account password, if the user is not yet signed in.
The back end server returns the list of restorable items.
In this scenario, the application displays the available items to the user.
The end user selects which item to restore, or selects to restore all items in one go.
The application triggers a restoration process using the in-app purchase API, repeating the process for each item that is being restored.
The back end server delivers the content or service. The end user can now access the restored content or service in the application.