Skip to main content

Development guidelines

Follow the development guidelines below when developing a PTS that uses the Transaction API.

Note

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.

Note

If you send requests exceeding the rate limit, you will receive an error message saying, 429 Too Many Requests.

Operation tests within rate limits

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.

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 requestRequest methodAPI EndpointStatus code
8e36bade-c5d6-4d00-9e69-72244675a9a1Mon, 05 Jul 2023 08:14:35 GMTPOSThttps://api.pts.com/merchant/payment200

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 addressTime callback was receivedRequest methodRequest pathStatus code
203.0.113.1 Mon, 05 Jul 2023 08:10:00 GMTPOST/pts/callback200
Additional information that would be useful to keep in log

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

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.