Last updated
Last updated
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).
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 ().
(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.ne)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.)
Transactions Taking Place in Non-ONE store Supported Countries
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.
When sending country codes and currency codes, please note the following:
Country codes are transmitted based on ISO_3166-1_alpha-2 for transactions occurring in countries not supported by ONE store.
Currency codes are transmitted based on ISO_4217, following the country code. If transactions occur in a currency different from the country's currency, it will be converted to the country's currency for transmission (Google search, as of 00:00 on the same day).
In cases where the country code is KR, the x-market-code in the Request Header is sent as MKT_ONE.
In cases where the country code is not KR, the x-market-code in the Request Header is sent as MKT_GLB.
Once confirmed by the ONE store's review team, if the correct transaction history is not delivered, the validation rejects or sales suspension may be processed.
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.
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.
The 3rd party payment purchase history has been updated. (send3rdPartyPurchase-p1)
If you are using the existing 3rd party payment purchase history transmission specification, you cannot distribute your app to the United States.
When servicing the app in the United States through 3rd party payments, you must use the send3rdPartyPurchase-p1 specification.
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.
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)
Response Body
Example
It is the detailed specification for transmitting to ONE store server the purchase/cancellation history of the 3rd party payment.
Desc: The developer transfers the history of the purchase made by using the 3rd party payment method.
URI: /v6/purchase/developer/{packageName}/send/p1
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
Desc: The developer cancels the history of the purchase made by using the 3rd party payment method.
URI: /v6/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
Error Codes
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.
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.
Example
3rd Payment Tax Policy
If developers sell products through 3rd party payments, they are responsible for paying value-added tax (VAT) and other related taxes in the respective countries. This means that developers should directly pay VAT and related taxes in each country. (However, for sales in South Korea, ONE store will handle the reverse charge of VAT on behalf of developers located outside of South Korea only.)
3rd Party Payment Service Fees
Developers located in Korea: Amount Subject to Settlement * 5% * 1.1 (including VAT / tax invoice issued)
Developers located outside South Korea: Amount Subject to Settlement * 5%
Amount Subject to Settlement : Sales amount (including VAT) - VAT
Fee Document
Developers located in South Korea: Issued with one tax invoice (covers both South Korean and global sales) (However, in the case of sales in South Korea, as it is a joint venture, separate fee documents will be issued by ONE store, KT, and LG U+.)
Developers located outside South Korea: Issued with one invoice (covers both Korean and global sales)
The path to check the documents is as follows: - Developer Center > Payments > Payments and Financial Report > 3rd party payment > Proof
Remittance
The service fee must be deposited into the designated virtual account by the 25th of the month following the sales month.
The path to check the virtual account is as follows: - Developer Center > Payments > Payments and Financial Report > 3rd party payment > Settlement Info
For developers located outside of South Korea, the total amount, including the service fee and the VAT reverse charge, must be deposited.
All fees incurred from foreign currency remittance (inward remittance) from overseas banks are the responsibility of the remitter. When making a SWIFT transfer, please ensure that the remittance fee option is set to OUR (responsibility of the remitter). (Please confirm the OUR option setting with your remitting bank.)
Editing Document Information
Unpaid Fees
The service fee is based on the final amount that ONE Store can receive. If only a portion of the payment is paid due to deductions such as transfer fees, it will be considered as "unpaid".
If fees remain unpaid, services may be restricted, including the discontinuation of product sales, in accordance with the sales agreement.
If you need to edit member information on the tax invoice(Invoice), please request it from the Developer Center () by the end of the sales month.
For more information, please feel free to send an email to ONE store Developer Center. ()