< NOTE >

This documents are for ONE store IAP SDK v16(API v4). If you are looking for the latest version of ONE store IAP SDK v17(API v5), please refer to the url below:

URL for the latest documents and downloads of ONE store IAP SDK v17(API v5) : https://dev.onestore.co.kr/devpoc/reference/view/IAP_v17

ONE store provides two types of the server API to allow you to check if the user has legitimately purchased the items.

This API intends to check the In-App purchase history of the user by using the TID issued at the time of purchase request by the developer.

This API allows you to verity if TxID and receipt is issued in the IAP server via the verification server and to identify if the purchase history exists by using the TxID and receipt issued at the time of purchase completion by ONE store. (This feature is provided in the SDK, however a serer-to-server call is recommended if there is a separate developer server.)

This API checks the purchase history by using as a key the TID, which is generated at the time of purchase request (sendPaymentRequest) and sent by the developer.

Notice

• It is recommended to use the e-receipt verification API if the App server is not run.
• The developer is required to manage the TID value as a unique value.
• In case the purchase requests are made using a duplicate TID, the TID is assigned to the latest purchase request and it is not available to check the previous purchase history.

Request URI

Reference

Up to 20 TIDs can be requested according to the number of TIDCNT, and the TIDs are differentiated using ‘|’.

Sample

• Example: request to IAP Server for development

http://iapdev.tstore.co.kr:8082/billIntf/billinglog/billloginquiry.action?DATE=20160715&APPID=OA00027256&TIDCNT=2&TID=12313|12324

• Example: request to IAP Server for commercial use

http://iap.tstore.co.kr:8090/billIntf/billinglog/billloginquiry.action?DATE=20160715&APPID=OA00027256&TIDCNT=2&TID=12313|12324

Reference

Status

Detail

This API can verify an e-receipt whichi is issued after an In-App product is purchased. It can send a request to and receive a response from the App2Server through the SDK. When it comes to the e-receipt verification, you are allowed only to check the verification histoy within 10 minutes after the completion of purchase. Currently, only a single inquiry is available.

Built-in Model

As for the Built-in Model that works without connecting to the server, you receive a notification of payment completion via the IAP library within the App. You can confirm if the payment of the corresponding product is successfully completed in the IAP server through the following connection flow before issuing items (including granding permission).

Line: required

Dotted line: optional

Server to Server

For the product connected to the server, the server-to-server feature is provided to request the verification of the e-receipt, which is issued through connecting with the IAP server in the App server. The following scenario is an example, and the feature can be properly implemented depending on the App service scenario.

Line: required

Dotted line: optional

The request data has the JSON format, and detailed specifications are as follows:

Request URI

Reference

Sample

{
	"txid":"TSTORE0004_20150515102510XXXXXXXXXXXXXXX",
	"appid":"OA00012345",
	"signdata":"MIIH7QYJKoZIhvcNAQcCoIIH3jCCB9oCAQExDzANBglghkgBZQMEAMIIH7QYJKdDFDFFEFEFEFoZIhvcNAQcCoIIH3jCCB9oCAQExDzANBglghkgBZQMEA" 
}  

The IAP server verifies the e-receipt included in the request protocol, converts result values into the JSON data and passes the JSON data to those who made the verification request.

Reference

Product

Status

Detail

Sample

{
	"status" : 0,
	"detail" : "0000",
	"message" : "successful verification completed", 
	"count" : 1,
	"product" : [{
		"log_time" : "20120321154451", 
		"appid" : "OA12345678", 
		"product_id" : "0900012345", 
		"charge_amount" : 1000,
		"tid" : "201012226_01047637315_00000239",
		"detail_pname" : "custom product name ",
		"bp_info" : "X"}]
}

Notice

Since attempts can be made to illegally acquire items in a range of ways in the Android App, the response content passed from the IAP server must be additionally identified in the App server to process the issuance of items. It is strongly recommended for you to follow the instructions below to block multiple illegal attempts in the App server:

• Confirm if the information of a product which requests the issuance of items in the App matches up with the information (appid, product_id, charge_amount, etc.) responded via the e-receipt verification API.

• Check the purchase history time (log_time) and refuse to issue items for the purchases which were made more than a certain amount of time ago(less than 5 minutes are recommended).
• If an item is successfully issued to a certain TID, save the corresponsing history. Any request for the issuance of the item to the same TID should be considered illegal, and such request must be rejected.
• If an App abnormally terminates or a network error occurs in the processing of payment, it is recommended to use a logic in which the purchased item is allowed to be used after identifying the purchase history using the sendCommandRequest method