In developing the Woocomerce plugin, I realized that there could be some potential problems with the once-per-second frequency restriction of polling ETN’s servers for payment confirmation as mentioned in the API guide. This is true for web-based stores in particular, and especially for large-scale projects like e-commerce stores that have several payments processing simultaneously at any given time.
Let’s say the seller implements a feature that continually checks in the background for payment confirmation on the payment page so that the page can update automatically upon payment. Let’s say he checks this once per second. This would be fine for one order running at a time, but multiple orders running concurrently would exceed one request per second.
An obvious solution here would be to increase the timing between AJAX updates to, say, 3 seconds. This would detract a little from the “instantaneousness”, but moreover, if two different orders were started within microseconds from one another, you would still end up firing 2 requests within a second. Perhaps the seller could integrate a background check that records the timestamp of the last poll and makes sure the next poll only fires one second later, though this would increase development complexity somewhat
The correct way would most likely be to implement the webhook and have it process the payment directly. Then have the front-end AJAX poll your local database (instead of the ETN API) every second to check for order completion. This is how the Woocommerce plugin currently works, with some fallbacks to poll once per page reload if the web developer neglects to insert the correct callback URL on Electroneum’s vendor page.
At this stage, this issue is most likely not a problem at all, given the early stage of the beta. But I’m just putting it out there to start the conversation and get some ideas on how large-scale installations can handle this.
Any suggestions on how the frequency restrictions can be lifted, but with some checks in place to prevent DDOS or spamming? Some solutions I could think of are:
- Allow more than one request per second, but impose a once-per-second limit on polls that have the same payment ID.
- Have big players apply for lifted restrictions and consider them on a case-by-case basis.