Hive Uniqueness: Making Recurrent HBD Payments

over 2 years ago

Did you know that you can make recurrent payments on Hive? Or more importantly, did you know that you can accept them?

This important feature was added in the last hard fork and does not get enough attention. With the recent focus upon HBD, it is time to highlight this vital feature. When it comes to commerce, especially online, recurrent payments are crucial.

For those who do not understand what this means, a recurrent payment is one that is scheduled once yet happens repeatedly. With Hive, we have the ability to schedule 12 payments.

This is ideal for the subscription model. We all signed up for something via this method, only to have our credit card billed each month.

It is a feature that, as far as I know, is unique to Hive, at least at the base layer.

A Great Way To Pay For Business Expenses

One of the powerful use cases of HBD is as a medium of exchange. The ability to pay for needs goods or services is a part of the evolution of the stablecoin. For that reason, incorporating the recurrent payments feature could be helpful.

Let us say, for example, that one has a server payment due each month. Naturally, missing this is not something that is desired. Therefore, a company might want to set this up automatically so that it is worried about.

The feature is available in the wallet in some of the front ends. Here we will show PeakD.

We start the process by hitting "SEND" HBD in the wallet. The normal transfer window pops up.

Here is the first thing we notice.

To set it up, we simply fill in the information like we are sending normally. However, we see this at the bottom of the window.

When we turn this one, we can see how the recurrent payment portion opens up. We now have the number of occurrences we can set. We also determine how often they are to take place.

In this example, the payment was set low enough at .001 HBD to enable a lot of payments. However, if it was kept at 2 HBD, the system would limit it to two transactions.

Nevertheless, we can see how this is easy to set up. Please note, the first payment will be sent immediately.

The Subscription Model

This is one of the most important business models in use today. Companies such as Amazon, Netflix, Apple, Tesla, and you local gym all utilize this model.

Having this available on Hive helps to set it apart. For the moment, it is vastly under utilized along with being rarely discussed. Since the hard fork, very little was said about it. This means that feedback was non-existent.

Certainly there are way to improve the system which should be coded in. However, to do that, the core developers (@howo in this instance) require some community involvement. To get to that point, we need to get some utility going.

Even in this form, businesses can start to utilize the feature. The schedule once, pay many feature can make people's lives a lot easier. Also, increased usage will give incentive to the front ends to update things such as notifications.

There are trillions of dollars a year in commerce done around the globe using this model. If cryptocurrency is going to take into it, we are going to have to offer the same features.

Hive is starting this process. With the rising interest in HBD, this is a feature at the base layer that is worthy of expanding.

Personally, the one aspect I could see changing is the inability to schedule if the total liquid HBD is not in the account. To me, as long as the double-spend cannot take place, users should be able to program in what is needed. Of course, if the funds are not there on the day it is to be sent, we can see system tries and then records a fail.

For example, presume a 100 HBD per month server expense. To schedule 60 payments means having 6000 liquid HBD. Why is this necessary? Unless there is something inherent in the base design of the blockchain, the scheduling should take place. Under this scenario, there would have to be 100 HBD available, which is sent immediately. After that, the balance needs to be at least 100 for the transaction to go through.

Using an example in a vacuum sounds a bit trying. However, if you think about a business, having 100 HBD in an account at any given time might not be a problem. However, having a large number at the time of scheduling could be. Thus, if the company is active, once their scheduling is set up, then the money will be there from simple operations.

What are your thoughts on this? Are there some use cases that you can think of where this is a handy feature? Can you see some ways to improve this feature on Hive?

Let us know in the comment section below.

If you found this article informative, please give an upvote and rehive.

gif by @doze

logo by @st8z