Internet services that provide utilities charge your bank account in pre-determined intervals, generally monthly. This is a well-established practice and quite a common merchant-customer relationship these days. However, technically, nothing prevents your bank or payment provider from charging you more than you owe, except moral and legal obligations. In this article, we are going to unveil how to set up recurring billing on top of a decentralized data platform in order to practically guarantee and enforce the billing rules on which both parties agreed.
Despite the fact that blockchain is facing a lot of adoption and regulation difficulties in 2018, it’s a kind of technology which is here to stay, whether it’s blockchain, hashgraph, tempo or any other distributed ledger technology still to come, regardless of the algorithm.
The main value that blockchain and other similar technologies bring can be generalized as follows: they allow people to write and run programs which, practically, cannot be changed after creation nor tampered with during execution. In other words, these programs always run as designed, and no single party can influence their behavior.
This definition is valid for many cryptocurrencies that exist today if we consider them as programs that define how coins can be transferred back and forth. This also explains why cryptocurrencies and many kinds of tokens have real value: they cannot be generated out of thin air, by their defined “underlying programs”.
Due to various kinds of regulations, one cannot simply create their own legitimate and easy-to-use crypto coin. Well, technically, they can. However, once there is a question of exchanging this crypto coin with fiat currency (for example, US dollars or Euros), regulations kick in.
Imagine if every business had a right to issue and exchange their own currency, — the possibility exists for a substantial amount of money to be laundered or circumvent taxation. Moreover, the world has become accustomed to credit cards, and building a business around something that you cannot just buy with your credit card is quite complex.
Finding proper, common sense regulations for crypto is an on-going process, and until they are realized, exchanging it won’t become easier. However, this complication is not related to the whole blockchain space; there are a plenty of examples of non-financial blockchain applications, where regulations are not needed at all.
Smart contracts can help us with any kind of agreement, but only with tokenized assets — a value directly registered in blockchain in the form of tokens or something similar. Blockchain cannot guarantee that your bank will release your money on time (unless your bank is built on top of it), but blockchain can guarantee the delivery of tokenized assets, because tokens can be programmed, unlike dollars.
In this article I am going to use ERC20-compatible tokens on top of the Ethereum platform as an example, though much of this applies to other decentralized platforms which support “smart contracts”, or in other words, decentralized (distributed) programming.
There are two options for how recurring billing can be implemented in terms of smart contracts. The first option is to code recurring billing functionality directly into a token smart contract (a program which defines how decentralized network participants can share tokens). However, in Ethereum and many other “truly” decentralized platforms, once you create a token smart contract you cannot change it anymore. That’s why tokens have real value after all and it is the whole point of blockchain.
To avoid hard-coding recurring billing functionality, ERC20 standard brings another, extendable option, without compromising security. According to ERC20 standard, a token smart contract must implement the approve and transferFrom functions, which create a complete framework allowing the extension of token functionality in any arbitrary way. To implement recurring billing, for example, we write a second smart contract, and then token holders approve this contract to charge their tokens. Thus, allowing a smart contract to charge tokens is an analog to signing a paper contract, where you have an exact statement (smart contract code) of how your tokens will be used.
We, at DreamTeam, have developed a recurring billing smart contract for the DREAM token, as well as a smart contract factory that you can use to create the same recurring billing smart contracts for your own tokens! Here is the algorithm of how token recurring billing is implemented.
The complete documentation on recurring billing smart contract factory and a children smart contracts is available in DreamTeam’s GitHub (smart-contracts repository).
The picture below demonstrates the recurring billing flow within a recurring billing smart contract.
Recurring Billing Smart Contract Workflow
Here’s how it works:
By using a recurring billing smart contract, Customer can be sure that Merchant is not able to charge them more than they agreed on, while Merchant has a convenient way to charge customers from an automated back end rather than just performing charge transactions manually on a regular basis.
How back end interacts with a smart contract
Now, we distinguish accounts that are allowed to perform charges from a merchant “admin” account to allow merchants to set up their automated back end which performs charges. However, we always assume that accounts on a back end are unreliable and can be compromised at any time.
It’s not possible to run transaction publishing on the back end without revealing private keys somewhere in the system (even if they are hidden in encrypted memory/storage). Thus, the only true and secure solution is to limit a smart contract’s functionality for accounts used on a back end, so that the possible attacker won’t be able to harm the system in any way except just stealing some Ether (Ethereum currency that is required for publishing new transactions). The charge (billingID) function is restricted on the smart contract level, and by compromising back-end accounts, an attacker won’t be able to perform any unauthorized charges nor change the token recipient address.
Developing a secure and stable back end for solutions on top of Ethereum is a whole big topic that I am going to cover in my next articles. Subscribe to my blog to stay updated!