This topic describes how you can develop a billing system for your application, to allow users to make purchases within your application.
Samsung Checkout offers an optimized purchase experience for your users on Samsung TVs. The user can quickly and safely register a payment method and make frictionless payments repeatedly within the TV environment. In addition, Samsung Checkout provides a comprehensive global monetization platform, which allows you to integrate various business models and promotional campaigns into your services.
The TV-optimized purchase experience provides the user a quick and simple 3-step checkout, once a payment method is registered. The checkout requires only number-centric information to be entered, making it easy to use with a TV remote control. Users can register their payment method directly on the TV or through a mobile phone.
To use Samsung Checkout, the user needs:
You can manage your product application and product sales through the DPI (Digital Product Inventory) and process the actual purchase through Samsung Checkout.
When a user wants to purchase a product on your application, Samsung Checkout provides a common purchase GUI, which identifies the user and confirms first the purchase and then the purchase completion. After the user completes the purchase, Samsung Checkout returns the purchase result to your application.
The following figure illustrates how you can use Samsung Checkout and the information in the DPI server to manage in-app purchases and payments in your application.
Request the purchase list:
Request the product list. Request the product information list using a Products List API request.
The user purchases the product:
Request the purchase list. Update the customer purchase list.
Verify the purchase. Verify the purchase using a Verify Purchase API request.
Apply the product. Apply the product using an Apply Product API request, and send the application result to the server.
The DPI service provides information on buyable products in your application and the purchase history of your customers. It serves the appropriate product information for the user's country, provides user-specific purchase information, and manages applying the product after purchase. The DPI service also assures purchase integrity and provides security through preventing fraudulent access.
The DPI service environment is divided into 2 separate zones:
Operating Zone (PRD) for live production applications When you submit your application for publishing, set it to use the operating zone.
Staging zone (DEV) for development and testing The purpose of the staging zone is to facilitate the billing linkage development. This environment minimizes the exceptional country-specific cases that can happen when real payments are made in the operating zone. The staging zone also includes a dummy payment testing option, where the user does not need to register any payment method, but can still use all the DPI services as in real payment transactions.
Table 1. Dummy and actual payment screens
The following figure illustrates the DPI service environments.
Implementation information for each DPI service environment is described in the following table.
buyItem() method 2nd parameter: "PRD"
buyItem()
Example:
var urlDPI = "https://checkoutapi.samsungcheckout.com/openapi"; var serverType = "PRD"; var securityKey = "*****"; // Your security key issued by DPI portal // (Can be different from Sandbox's security key)
buyItem() method 2nd parameter: "DEV"
var urlDPI = "https://sbox-checkoutapi.samsungcheckout.com/openapi"; var serverType = "DEV"; var securityKey = "*****"; // Your security key issued by DPI portal
buyItem() method 2nd parameter: "DUMMY"
var urlDPI = "https://sbox-checkoutapi.samsungcheckout.com/openapi"; var serverType = "DUMMY"; var securityKey = "*****"; // Your security key issued by DPI portal
When you submit your application for publishing, make sure that it has been fully integrated with the billing system:
When the user registers their credit card as a payment method in Samsung Checkout, they can do it through their mobile phone or computer Web site by entering the authentication code.
When you are creating a test user for your application, pay attention to the URL you use to enter your authentication code and register a payment method. Each URL requests a different server to handle the payment:
In case that partner already has CMS server which manage products and price, and it is required to change the product information frequently, partner and Samsung can discuss to use dynamic product when they integrate Samsung Checkout.
And once they agree on that products and prices will be managed by CMS of partner not by Samsung’s DPI, partner need to register a representative item on DPI so that Samsung Checkout system can display information on Samsung Smart TV App/Game store which is legally required.
Partner does not need to register each products on DPI that they sells in their app, however, They should builds and operates its own CMS to manage products information including prices and provide rest API for verification of purchase requests.
The following figure shows data flow of initialize stage in payment process with dynamic product.
As model require Partner CMS to manage product information, there is additional requirement that partner need to do for DPI settings.
Verification/No Verification ‘Verification’ is a recommended option otherwise partner has to handle the verification process by themselves and take all the responsibility for all the error cases related to verification process. If ‘Verification’ is selected, ‘Verify URI’ is also required. This URI should serve the function of checking product information such as product itself, price and currency in sequence of initialization during payment process.
Price Setting Price range information of products that you actually sells in your app is required by country. It is not used for actual payment for providing the app information on Samsung Smart TV App/Game store which is legally required. Thus, it has to be updated when the price range of your products is changed.
When buyItem() Unlike ordinary purchase, when Dynamic Product, Partner need to set values as below in order to complete payment process. "OrderItemID" - Representative productID that registered to DPI Portal as dynamic product type "OrderTitle" - Customized name for each purchase displayed as in Figure 9. "OrderTotal" - Customized price for each purchase displayed as in Figure 9. "DynmcProductID" - Unique product ID managed by Partner CMS
When Verify Product Partner need to strictly verify the below values in order to identify if it's appropriate product information. "appId" - if it's appropriate application for this payment process "productId" - if this is same as representative ProductID from DPI Portal "productPrice" - if price of product that partner intended to sell to user "dynmcProductID" - if this is is appropriate ID that are under control of partner CMS
Verify Product