Payments of Tomorrow: Decentralized Recurring Billing

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.

Blockchain and Distributed Ledger Technology

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”.

Will Regulations Kill Cryptocurrency?

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.

Recurring Billing in Blockchain

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.

Workflow and the Recurring Billing Smart Contract

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.

• It works with two entities: Merchant and Customer. Merchant inserts itself in a smart contract to charge and receive tokens, whereas Customer attests that a particular merchant is authorized to perform charges.
• All approved recurring billing has a Billing ID used by the merchant to charge the customer’s account. One customer account can have multiple active billings at the same time.
• Merchant, along with its “merchant admin” account, can choose a specific account to receive tokens (beneficiary account), and accounts which are allowed to charge customers. We distinguish these accounts intentionally.
• The recurring billing smart contract factory allows the creations of new recurring billing smart contracts for each token individually.

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:

1. Merchants inserts themselves into a smart contract and retrieve a Merchant ID, which is used to identify with which merchant the customer agrees.
2. The customer allows a recurring billing smart contract to charge their tokens. At this step, the smart contract still does not allow the merchant nor anyone else to benefit from the customer and does not charge the customer.
3. The customer tells the recurring billing smart contract that it’s allowing a particular recurring billing, providing the ID of the merchant and billing properties defined by the merchant like period and value.
4. From this moment, the merchant can charge the customer’s account by making a charge transaction to a smart contract, but not more than once in a specified period of time. On each charge, tokens go directly from the customer’s account to the merchant’s beneficiary account.

Back End Security

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!

Resources

• Recurring Billing Smart Contract factory (source code, documentation).
• How to verify your recurring billing smart contract code on Etherscan.
• Presentation of blockchain recurring billing and back-end solution (in Russian).

Payments of Tomorrow: Decentralized Recurring Billing was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.