Development guidelines
Follow the development guidelines below when developing a PTS that uses the Transaction API.
The basic rules for PTS development are based on what is stated in the terms and policies.
Prohibiting mass requests to the PTS Platform
Don't send a large number of requests to the PTS Platform for the purpose of load testing or operation testing.
Don't send requests beyond the specified rate limits for any purpose.
If you send requests exceeding the rate limit, you will receive an error message saying, 429 Too Many Requests.
Even within rate limits, sending the following requests at a high frequency is prohibited.
- Repeatedly creating transactions that are not actually used for sending orders
- Repeatedly making requests that aren't for the purpose of using the features provided by the Payment / Withdraw API
Prohibiting PTS Platform load tests
here is no service to load test servers from the PTS Platform.
For load testing purposes, don't send large numbers of transactions via the PTS Platform. Prepare a separate environment for load testing of servers.
Prohibiting mass transmission to the same channel
Don't send too many transactions to the same channel for any purpose.
Prohibiting requests for non-existent channel IDs
When sending a request, don't specify a non-existent channel ID.
Prohibition of acts that identify the attributes of channel ID
Don't attempt to identify channel attributes for a specific channel ID. Also, don't use the Managing Audience API or deliver narrowcast messages for the purpose of identifying channel attributes.
Prohibiting IP address restrictions
On servers that receive callbacks, don't restrict access by the IP address of the PTS Platform from which the callback request is sent.
We don't disclose IP addresses of the PTS Platform. Also, IP addresses are subject to change without notice.
To deny requests from unauthorized sources, use signature validation instead of access control by IP address.
Recommended processing on receipt of unsend event
When a channel unsends a sent transaction, an unsend event is sent to the server.
When the unsend event is received, we recommend that service providers respect the channel's intent to unsend a sent transaction and handle the transaction appropriately with the utmost care so that the target transaction can't be seen or used in the future.
For more information, see Processing on receipt of unsend event.
Saving logs
We recommend saving logs for Transaction API request and callbacks received for a certain period of time so that developers themselves can smoothly investigate the cause and scope of a problem when it occurs.
Logs for Transaction API request
We recommend saving the following information as a log when making a request to the Transaction API.
- Request ID (x-pts-request-id) of the Response header
- Time of API request
- Request method
- API endpoint
- Status code returned in response by the PTS Platform
More specifically, save it in a log file using the following format.
Request ID (x-pts-request-id) | Time of API request | Request method | API Endpoint | Status code |
---|---|---|---|---|
8e36bade-c5d6-4d00-9e69-72244675a9a1 | Mon, 05 Jul 2023 08:14:35 GMT | POST | https://api.pts.com/merchant/payment | 200 |
Logs for callbacks received
We recommend saving the following information as a log when you receive a callback from the PTS Platform through the server.
- IP address of the callback sender
- Time callback was received
- Request method
- Request path
- Status code the server returned in response to the received callback
More specifically, save it in a log file using the following format.
Sender IP address | Time callback was received | Request method | Request path | Status code |
---|---|---|---|---|
203.0.113.1 | Mon, 05 Jul 2023 08:10:00 GMT | POST | /pts/callback | 200 |
Depending on the requirements of the server, the following information, in addition to the above, can be stored for investigation when problems occur.
- Transaction API request body
- Response body returned by the PTS Platform after the API request
- Signature (x-pts-signature) of the request header when callback is sent from the PTS Platform
- Callback event object returned by the PTSE Platform
We don't provide logs of Transaction API requests, or logs of callbacks sent from the PTS Platform to the server, etc. despite inquiries. Logs should be saved by the PTS developers themselves.