Billing_3rd party
What is 3rd Party Payment?
The 3rd party payment is a payment service provided by the seller (hereafter called the “developer”) through direct interworking with Payment Gateway (PG) without the application of ONE store’s in-app payment module (in-app SDK).
How to Apply 3rd Party Payment
- Transfer Transaction History
When 3rd party payment is used, the transaction history of the 3rd party payment (purchase history, cancellation history) must be transferred to ONE store and the development and review of this 3rd party payment service is needed.
The transaction history delivered to ONE store will be utilized for ONE store’s ranking and service and as data for settlement between ONE store and the developer.
(A) [Developer] Register new app through ONE store Developer Center > Apps > 'Product Registration' button.
On the product registration screen, set the '3rd Party Payment method' option to 'Use'.
In the 'Agreement to use 3rd Party payment method' pop-up, you have to agree to click 'confirm'.
(B) [Developer] You can get OAuth Key (Client secret) issued on the product registration screen.
(C) [Developer] Development shall be made with reference to Server API Specification.
Issuance of an OAuth Access Token and the transmission of the transaction history, etc. shall be developed.
(D) [Developer] The developer is required to confirm that the transaction history has been normally transmitted in the Sandbox environment (https://sbpp.onestore.co.kr).
(E) [Developer] To be reviewed by ONE store, the final APK shall be uploaded on ONE store Developer Center and shall interwork with the commercial environment.
The commercial environment of the developer must interwork with that (https://apis.onestore.co.kr)of ONE store, and
the 3rd party payment gateway company interworking with the developer must interwork with the commercial environment of ONE store.
(F) [Developer] A review request shall be made.
(G) [ONE store] ONE store is required to make payment in the developer’s app and confirm the transaction history has been normally sent to the commercial environment.
(H) [ONE store] ONE store shall request the developer to cancel the 3rd party payment used for review (by sending a request email to the developer’s person in charge).
(I) [Developer] The developer shall process the requested cancellation of the transactions used for review.
(J) [ONE store] ONE store shall confirm that the history of the cancelled transactions has been sent to the commercial environment, and then complete the review process.
(K) [Developer] The developer can process to start the sales of the app for which review has been completed.
- Criteria for Transmitting Transaction History
The criteria for transmitting the transaction history is as follows:
3rd party payment occurs,
when items are directly purchased by using 3rd party payment methods.
when the in-app goods* are recharged by using 3rd party payment methods. (*the in-app goods : goods that can be charged only within the app and items can be purchased with this goods only at that app)
when items are purchased by using the developer’s own payment methods**. (**the developer’s own payment methods : payment methods that can be purchased by using 3rd party payment methods through other channels such as other apps or web of the same developer and used by multiple apps of the developer)
Exceptional cases occur (3rd party payment does not take place),
when items are purchased by using the developer’s own promotional payment methods (free coupon, point cash, etc.)
Transaction history is confirmed based on Purchase ID(developerOrderId).
The app using 3rd party payment options is required to offer purchase ID to the user ‘when the 3rd party payment is completed’. (in the payment completion screen and in the email notice)
ONE store’s review team shall confirm that the transaction history has been normally sent to ONE store on a basis of the purchase ID when the 3rd party payment /cancellation is made for this app.
If the payment method you use is foreign exchange or encryption money, please note the following:
The transaction amount on the '3rd party payment developer guide' shall be transferred in Korean won at the same date. (Google search, based on 00 o'clock on the day)
Once confirmed by the ONE store's review team, if the correct transaction amount is not delivered, the validation rejects or sales suspension may be processed.
Server API
- What is 3rd Party Payment Server API?
When the payment is completed (successful), the developer needs to have a process to send the relevant data to ONE store and synchronize the payment history. In addition, when a change (a cancellation) occurs after the payment and synchronization is completed, it is also required to transmit the history. The purchase/cancellation history of the 3rd party payment that has been transmitted to ONE store will be reflected on ONE store ranking and exposed to general customers and used as data for the settlement with the developer.
3rd party payment server API is an API, which is provided to transfer to ONE store the purchase/cancellation history of the 3rd party payment incurred to the developer.
send3rdPartyPurchase (transmits the purchase history of the 3rd party payment)
cancel3rdPartyPurchase (cancels the purchase history of the 3rd party payment)
OAuth authentication is required first for the interworking of each API, and for the OAuth authentication, client_id and client_secret should be issued in advance.
- Interworking Environment
ONE store API server is provided separately for Sandbox (the development environment) and the commercial environment according to its purpose.
Sandbox
is a virtual interworking environment to which commercial API standards have been applied as they are.
can be used for development review before launching the app on Developer Center once the development for interworking between ONE store and server API has been completed.
The payment data transferred from the developer will not be used for ranking or settlement.
The commercial environment
is a real service interworking environment where the payment history needs to be synchronized for completion or cancellation of the customer’s payment.
The data transferred to the commercial environment will be reflected on settlement. If a payment test is performed in the commercial environment, the payment MUST be cancelled.
Host information of Sandbox and the commercial environment is as follows.
- Transmit Purchase History of 3rd Party PaymentInterworking Flow
If the user requests a product purchase in an app, the app obtains information necessary for interworking (refer to 4. Reference Code)
The purchase request of the user along with the information acquired from the app is sent to the developer’s server.
Payment will be processed through 3rd party payment (PG company or in-app payment of other markets) in the developer’s server. The result will be sent to the app.
Simultaneously, the purchase history of the 3rd party payment will be transferred to ONE store API Server.
(In case ONE store OAuth Access Token expires,) it is required to get an OAuth Access Token issued and then perform API interworking.
It is recommended to save the result of the API interworking as a status value. If the interworking is in the failure status, perform retry.
Obtain Client Information
App installation market information
Mobile carrier information
Make Payment Request
Process 3rd Party Payment
Complete Payment
[When the OAuth Token expires] Issue an OAuth Token
Send Purchase History of 3rd Party Payment
- Cancel Purchase History of 3rd Party Payment
When the purchase history interworked to ONE store is cancelled, this cancellation history of the 3rd party payment will be transferred to ONE store API Server.
(In case ONE store’s OAuth Access Token expires,) it is required to get an OAuth Access Token issued and then perform API interworking.
It is recommended to save the result of the API interworking as a status value. If the interworking is in the failure status, perform retry.
- Caution
At the time when the payment is completed or cancelled, the developer is required to transfer the relevant data to ONE store on real time.
However, development is recommended to prevent the failed payment of items even if the transfer of the data to ONE store fails.
The developer is required to implement retransmission just in case when the data transfer fails due to errors in the network, etc. Ex) The data on the transfer failure is periodically re-transmitted by using the batch process
ONE store OAuth
Overview
For the interworking with Server API related to the transmission of the transaction history of ONE store, it is required to issue an Access Token through OAuth authentication.
The Access Token will be valid for 3,600 seconds. When the token expiration time expires or is less than 600 seconds, a new token can be issued by calling getAccessToken().
Existing Access Tokens can be used until the end of their expiration
Since numerous Access Tokens are issued, different Access Tokens can be obtained and used depending on the developer’s each service instance.
The general interworking flow is as follows:
The process to get an Access Token (no.1) shall be called when an authentication error occurs at the call of API.
To call ONE store Server API, the Authorization Bearer scheme shall be used. A sample of the call is as follows. (Bearer value is the value of Access Token, which has been issued by calling getAccessToken() )
Server API details
Desc: The developer transfers the history of the purchase made by using the 3rd party payment method.
URI: https://{host}/v2/purchase/developer/{packageName}/send
Method: POST
Parameter: String packageName : The package name of an app, which calls API (Data Size: 128).
Request Header
Request Body
Example
Response Body
Example
- cancel3rdPartyPurchase (cancels the purchase history of the 3rd party payment)
Desc: The developer cancels the history of the purchase made by using the 3rd party payment method.
URI: https://{host}/v2/purchase/developer/{packageName}/cancel
Method: POST
Parameter: String packageName : the package name of an app, which calls API (Data Size: 128).
Request Header
Example
Request Body
Example
Response Body
Example
- Code Table
- Payment Method Code (purchaseMethodCd)
When you use a payment method not defined in the table below, please make an inquiry to Developer Center (devhelper@onestore.co.kr).
Reference Code
This guide includes client development content to support the transfer of the transaction history of the apps, which are sold on ONE store by using 3rd party payment options.
The developer can check the contents provided as below and directly implement the functions, or use the contents with reference to the sample code.
Obtain App Installer Information
The application installed on ONE store will have a total of 8 install package information (Including Samsung Galaxy Store. See the chart below)
If the installer, which enables the app to be installed on ONE store with the following code, is ONE store, the payment information of such app should be transferred to ONE store along with the install package name.
If it is not possible to check whether there is an installer, "UNKNOWN_INSTALLER" will be sent.
Example
- Obtain Mobile Carrier Information
The mobile carrier information can be obtained from the USIM card and transferred through the ONE store 3rd party payment transaction history API.
The carrier information to be transmitted is the SIM Operator information of MCC + MNC combination and consists of 5 to 6-digit numbers.
If it is not possible to obtain the SIM Operator such as Wi-Fi Table, "UNKNOWN_SIM_OPERATOR" will be sent.
Example
Obtain Advertising ID
For the Google Advertising ID, the Google Play Service Library must be included in the project to get the value provided by the play service.
The Google Play Service Library guide can be added according to the following link.
Link : Google Link
If the user has opted out of receiving the Advertising ID, "UNKNOWN_ADID" will be sent
Example
Others
The total amount of the fee will be automatically calculated, and shown on the each developers settlement page. It is based on the total sales amount of the three major sales channel including ONE store, KT, and U+.
The fee should be paid to the virtual bank account of each developer, and the bank account number can be found on the developer's profile page or status of settlement page.
Totally three invoices will be issued from three major sales channels including ONE store, KT, and U+.
If the information on the invoice need to be updated, please contact us by the 5th day of the issuing month. (devhelper@onestore.co.kr)
- Technical / Policy Inquiry
For more information, please feel free to send an email to ONE store Developer Center. (devhelper@onestore.co.kr)
Last updated