FAQ

FAQ

What is Incoming Trigger Service?

Incoming payments of the cryptocurrency can be monitored by a program using JavaScript (Node.js). This service monitors incoming payments of the cryptocurrency (Ripple/XRP , NEM/XEM & Symbol/XYM) and provides POST requests to the program of the specified URL when notified.
* This mechanism is called webhook or event trigger.

Is this service charged?

This service allows you to register one cryptocurrency address for free. If you want to register 2 or more, you can register up to 5 (10 currently in the campaign) by paying the membership fee (2,400 JPY per year in Japanese yen) with Ripple, NEM, or Symbol. Since it is calculated on a prorated basis, you can transfer any amount of money, and use it for as many days as you need. However, please note that amounts less than the daily amount will be rounded down. Please see here for the detail. ⇒ Membership Payment

How can I use this site?

1.First,Membership registration (free) is required.

2.All functions are listed on Managing Triggers page.

If you register the cryptocurrency address and the URL of the program that starts at the time of incoming payments, it will be displayed in the list of registered addresses, and you can start/stop, update, and delete.
Update / Delete can be used after stopping.
The address in red is incorrect or unused, so please correct it with the update button before starting.
If there is a incoming payment in the ON (working) state, a POST request will be sent to the program at the specified URL.

3.On Access Log List page you can check the log data of the POST request result.

4.Monitoring Code page contains the transaction monitoring program code used in this service.

5.Historical Transactions page lists how to get the history of incoming transactions.

6.On Managing Account page, you can update and delete your account information.

7.On Membership Payment page,The membership fee can be paid by the cryptocurrency (Ripple NEM or Symbol).

What are the benefits of using this service?

A program using JavaScript (Node.js) is usually required to monitor incoming transactions in real time. For this reason, cloud services and VPS must be prepared, which raises the hurdle. However, by using our service, you can easily start php and perl programs uploaded to an ordinary rental server.
In addition, you must have your own node for reliable monitoring of incoming payment. This is because the trigger may not occur depending on the state of the node. This makes it even harder. This is also a big advantage of using this service.

What preparations are needed to use this service?

It is necessary to prepare a program to be activated at the timing of a incoming payment in the wallet and register its URL. This depends on the idea, for example:
1.A program that confirms transactions and processes them.
2.A program that you want to run Immediately after receiving money.
3.A simple program that notifies you of a incoming payment by email.
In addition, you can use the following test program for analyzing transactions (for the notification of incoming payments by e-mail).
https://program.triggersv.com/en/test.cgi
* If you register this URL, the notification of incoming payments will be sent to the email address registered in your account.
* If you pay the annual membership fee, you can get this test program for free (You can download it at other benefits for paid members on Managing Account page).

How is it different from polling using CRON?

Near-real-time processing can also be realized by running CRON every minute and checking transactions regularly, so-called polling. However, there is still some delay. On the other hand, Incoming Trigger Service enables simultaneous processing with incoming payments.
On the other hand, if Incoming Trigger Service fails, it cannot be repeated. CRON can be executed over and over again and is more reliable in this respect.
So you can achieve both real-time and certainty by using both. For example, you can use Incoming Trigger Service and use CRON every 1 minute at the same time. In this case, CRON will be insured if incoming trigger does not work.

What is the frequency of triggers?

This service calculates the frequency of triggers and sets limits. This is to reduce the load on the server and maintain normal operation.
The frequency of triggers indicates how many triggers have occurred per unit time, that is, how many incoming payments have been made. This is calculated for each currency based on the latest data. You can see its value on the Access Log List page.
If the value is large, the associated address will be stopped automatically. The stopped address is indicated by an orange address on the Managing Triggers page. You can find the value of this limit on the Access Log List page. This limit is subject to change.

What data is posted with POST requests?

The data to be POSTed is summarized in Data to be POSTed. For example, the key "data" is transaction data.
In the following test program for analyzing transactions notifying incoming payments by e-mail, the acquired transaction data is written in the e-mail. We recommend that you check it.
https://program.triggersv.com/en/test.cgi
* If you register this URL, transaction data will be sent to the email address registered in your account.
* If you pay the annual membership fee, you can get this test program for free (You can download it at other benefits for paid members on Managing Account page).

Tell me About HTTP Responses in the access log list.

The HTTP response of Access log list shows the response when an HTTP request is made to the specified URL (program). Then, if you check the displayed status code (statusCode), you can check the operation of the program. Here are some typical ones.
ESOCKETTIMEDOUT (3s)
Since the purpose is only to send POST, we set the timeout to 3 seconds, interrupt the process in 3 seconds after sending the POST request, and save the log. So, in this case, the response takes more than 3 seconds, which is not abnormal. The difference between the time when POST is sent and the time when the log is saved is usually about 3 seconds at the maximum.
500 Internal Server Error
The POST transmission has been executed, but the program cannot be executed.
200 OK
The response time of the program is less than 3 seconds, and there is no problem in operation.
ECONNRESET (connection reset)
This service made a POST request to the specified URL, but the connection was reset. In this case, the retry is repeated 5 times at reasonable intervals, but if it still does not succeed, this message is displayed. So the POST request may have failed. Conversely, POST requests may have been made multiple times.
* The same applies to ETIMEDOUT and ECONNREFUSED .

Why does the trigger sometimes not fire?

The trigger may not occur depending on the state of the node. Therefore, in this service, we prepare our own node and manage it so that the trigger will occur as surely as possible. However, the trigger may still not occur. We will cover some such cases.
* Please see this page for confirm(0) or confirm(1). ⇒ Regarding the number of confirmation
When the trigger of Ripple confirm(0) does not occur :
In the case of Ripple, there seems to be a few percent chance that the confirm(0) will not be triggered. But this is not unusual. Not all confirm(0) are triggered. ⇒ Listening to streams
When the trigger of NEM confirm(0) does not occur :
It may not occur at all depending on the state of the node. in this service, we manage it so that the trigger will occur as surely as possible. Furthermore, it seems that it may not occur depending on the state of the network.
When the trigger of Symbol confirm(0) does not occur :
In this service, the Symbol node (API & PEER) is set to minFeeMultiplier=25. Therefore, the confirm(0) for transactions with a fee of less than 0.0044 (Slowest) will not occur. However, normally, a higher fee should be set when sending money, so unless the fee is low, the trigger for confirm(0) will occur. ⇒ Occurrence condition for the trigger

Here are some other cases.
When the trigger of Ripple confirm(1) does not occur :
In the case of Ripple, the trigger for the confirm(1) may not occur even when the trigger for the confirm(0) occurs. An example of such a case is insufficient funds. These causes can be confirmed in the transaction data of the confrim(0).
When the trigger of Symbol confirm(1) does not occur :
If the transaction fee is low, the confirm(1) trigger may be delayed or may not occur in some cases. However, since the node is set to minFeeMultiplier=25 in this service, if the trigger for the confirm(0) occurs, the trigger for the confirm(1) will occur usually after about 30 seconds, at the latest after a few minutes.