An online retailer provides a centralized payment process: the payment (or an authorization to withdraw) is first received from the buyer and then is transferred (or is withdrawn from the buyer account) to the seller via the retailer when the purchased item is delivered.
How to decentralize the payment process with the blockchain technology? That is how to replace the centralized retailer organization which serves as a trusted third party to transfer the payment from the buyer to the seller?
The challenges to address are:
- how to ensure the seller that the buyer is willing to purchase?
- who is responsible for transferring the payment to the seller?
- how to manage item delivery failures?
The basic principle of an escrow contract is to hold the payment transferred by the buyer and to relase it to the seller when the delivering process is achieved.
The purchase process starts when the buyer creates the escrow contract and transfers or the payment to it (ie. funds it). The seller is notified thanks to a dedicated contract indexer. A contract indexer is an off-chain permanent process that monitors and analyses newly created contracts.
At this stage the seller may abort the contract for any reason, typically when the retailing web page is not synchronized with the seller's reality (out of stock situation, change in price, and so on):
- if aborted by the seller, the escrow contract transfers the payment back to the buyer
- if accepted by the seller, then transit of the purchased item may occur
The next step is to transfer the payment to the seller when the item is delivered. For simplicity purpose, we consider the item is properly delivered. The situation of delivery failure is addressed in the discussion section below.
Ideally the buyer transfers the payment to the seller when the item is delivered. However what does prevent the buyer from not transferring the payment?
In order to address this issue, the idea is to create a security deposit that is transferred at contract creation. In this DApp the security deposit is 110% of the item price. That is that in order to purchase a 100ꜩ item, a total transfer of 210ꜩ is required. In order to get back the security deposit, the buyer has to transfer the payment to the seller.
The figure below illustrates the main payment process:
- contract origination and funding with payment and security deposit
- seller accepts the contract (with
acceptcontract entry point)
- buyer finalizes the contract (with
finalizecontract entry point):
- payment is transferred to seller
- security deposit is transferred back to buyer
The DApp architecture is 4-tier:
- escrow smart contract
- off-chain retailing web pages and content servers
- off-chain contract indexer
- off-chain seller's back office
For simplicity purpose, the contract indexer and seller back office interface are not provided in this DApp example.
The main operational benefit is the cost reduction due to the absence of centralized process. Plus the orginiation (deployment) and operation costs of the smart contract are very low.
Moreover the payment process is transparent since transfer rules are publically available as the smart contract execution code.
The payment process presented here does not handle the failure of delivery: indeed if the item is not delivered, the buyer cannot transfer payment, nor abort it (because the seller has sent the item).
In order to fix that, we need the delivery thrid party to ensure the payment process in case of failure: the delivery third party is given the authority to abort the payment and funds the contract with a insurance deposit; this deposit is transferred to the seller in case of delivery failure, and paid back to the delivery third party when the buyer finalizes the process, as illustrated below:
- the delivery third party (DTP) transfer the insurance deposit once the escrow is accepted by the seller
- 3 transfers when the delivery fails: buyer is paid back and insurance deposit is transferred to seller