Payment Patterns

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

As the killer application of blockchain technology, blockchain-based payments have attracted extensive attention ranging from hobbyists to corporates to regulatory bodies. Blockchain facilitates fast, secure, and cross-border payments without the need for intermediaries such as banks. The “money” used on a blockchain includes both cryptocurrencies and tokens. Cryptocurrencies are baked into the blockchain platforms as the base currency (e.g., Bitcoin and Ether) for transactions and provide incentives for blockchain platform operations (e.g., mining). Tokens are application-tier coins that are created and exchanged using smart contracts on the blockchain. Tokens may represent cryptocurrencies (e.g., Binance Coin and Uniswap) or used as a proxy for fiat currency (e.g., Tether and US Dollar Coin).

The following figure illustrates an overview of token-based payments. A token issuer issues a new token associated with a set of spending rules. One or more tokens are allocated to a buyer. For example, in food stamps, the issuer is the government agency that manages the program and buyers are the people classified as food insecure. The spending rules may specify eligible kinds of food, their quantities, and sellers. A buyer then purchases food products from a seller using the allocated tokens. A seller could be a supermarket that cashes out multiple tokens from the government agency. However, as different food stamps may carry different spending rules, it is in the seller’s best interest to validate them at the time of payment. This ensures that the seller can convert the collected tokens to fiat currency for the products it sold. Alternatively, the buyer may also want to know the authenticity of the product and whether the seller has the authority to sell it. Once redeemed, the issuer needs to destroy the tokens (aka., burn token) to ensure the tokens are not reused (i.e., double spend).

Because blockchain technology is still emerging, systematically organised knowledge providing a holistic and comprehensive view on designing payment applications that use blockchain is yet to be established. If such knowledge could be established in the form of a set of blockchain-specific patterns, architects could use those patterns in designing a payment application that leverages blockchain. Therefore, we present the following patterns that cover critical aspects in enabling the state transitions of a token in blockchain-based payment applications. The lifecycle and the annotated patterns provide a payment-focused systematic view of system interactions and a guide to effective use of the patterns.

• Token Template – Design tokens in a customised manner using a template smart contract that can be extended or instantiated
• Token Registry – Maintain the ownership information of tokens on a registry smart contract
• Policy Contract – Specifies the policies that a token must satisfy as a smart contract
• Burned Token (aka., Token Burning) – Once the redeem process is finalised, the spent tokens become unspendable.
• Escrow – Hold tokens on a third-party smart contract until the payment conditions are satisfied
• State Channel (aka., Payment Channel) – A 2-way pathway is established between transacting parties to perform transactions off-chain while recording opening and final settlement transactions on the blockchain
• Seller Credential – The buyer can validate the seller’s business qualifications through seller credentials
• Stealth Address – Use a one-time address for the transaction to protect the privacy of the parties involved in the transaction
• Oracle – To examine the fulfilment of payment conditions, an oracle is used to introduce the state of external systems into the blockchain execution environment.
• Multisignature (aka., Multiple Authorisation) – Given a pool of n addresses that could authorise a transaction, get a subset m of them to authorise a transaction by signing the respective transaction (m ≤ n).
• Token Swap – Trade between two types of tokens as an atomic transaction
• Authorised Spender – An authorised third-party spender can spend a certain amount of tokens owned by the approver