As the UPI payment ecosystem in India has grown by leaps & bounds in the past few years, one of the challenges that users are facing is the finality of transactions, or what one would call, the irreversibility of transactions for the sender. This has led to an uptick in online scams, primarily driven by social engineering, where trusting individuals are but a phone call away from some creative scammer looking to find his next victim. In many cases, scams are made easier due to the asynchronous nature of the deal setup – online transactions can happen instantly, whereas the physical delivery of goods/services takes time.
Some of the most common scams are where the seller decides to renege on his/her end of the bargain, leaving the buyer hanging after the payment has been made. However, we also should not presume that the pendulum should swing completely in the opposite direction – where no buyer should be expected to make any payment till the time the delivery is made, because that will lead to its own set of challenges (as popularized by prank calls to restaurants to order expensive food to someone else’s address without their knowledge).
Hence, we should find a middle path – one that expects a certain level of intent to be shown, without necessarily putting one party completely at the mercy of the other. One of the approaches worth exploring towards mitigating this issue with finality that arises in UPI is to leverage smart contracts, not unlike the ways they are used on blockchain networks like Ethereum. However, do note that since the actual transaction is actually being effected in the offline world, these smart contracts would need to be human-and-code-driven, not purely code-driven.
A simplistic example could be as under –
- Upon finalizing an agreement to purchase goods/services, the buyer initiates a transaction that loads money from their account into a smart contract using UPI and signs the transaction with an “offer to pay” label with a certain “agreed upon time window”
- Buyer sends the link to this smart contract to the seller, who can view that the funds have been loaded
- Seller confirms acceptance of the order and the expected timelines by signing the transaction with an “intent to deliver” label
- Seller then delivers on the goods/services as promised to the buyer, and asks the buyer to sign against the delivery with a transaction for a “confirmation of goods/services received” label
- Once the buyer signs this transaction, it automatically executes the smart contract, and the funds are instantly transferred from the smart contract to the seller’s account
This mitigates the problem of bad actors in a couple of different ways –
- In case of a bad actor on the buyer side, who has no intention of making the actual purchase, this approach requires the person to load fiat currency into the smart contract, thereby requiring liquidity in the bank + blocking it for an X amount of time
- The requirement for the buyer to load money into the smart contract reduces the likelihood that a seller will face a bad actor on the buyer side – as the seller is now seeing intent as well as liquidity (as opposed to the existing situation where the seller just has to go off the words of the buyer that he/she is not a bad actor)
- In case of a bad actor on the seller side, who has no intention of making the actual delivery, this approach –
- requires the seller to reach the delivery location with the goods/services, so as to get the payment effected
- enables the buyer to automatically receive his funds back after the completion of the “agreed upon time window” in case the “confirmation of goods/services received” label has not been signed by the buyer (in case of non-delivery)
In summary, this approach swings the pendulum back from the extreme of the buyer being at the mercy of the seller to hold up his/her end of the bargain after having sent across the money. At the same time, it prevents the seller from being at the mercy of the buyer, who might be lacking in intent or liquidity. This approach improves visibility to the intent and the liquidity available at the buyer’s end, without risking the buyer’s funds. However, considering that there are enough instances on scammers existing on the seller side, we believe that this approach will separate the good sellers from the bad actors, who will find it worth their while to proceed with transactions where buyers are showing intent + availability of funds.
Important note: This process is designed for transactions where the buyer and seller meet at the time of delivery.
However, in cases of asynchronous delivery (where the buyer and seller do not meet at the time of delivery), we will have to tweak the smart contract rules through a few variants –
- Use of timelocks that are triggered at every step that automate the flow of funds away from buyer towards the seller
- Introduction of checks and balances along the flow of funds, with the option to contest the completion of the transaction
- Any contestation of the transaction will reroute the decision-making to a paid third-party, whose decision will be final and effected directly on the smart contract
- There will be a cost associated with this re-routing, which will have to be borne by the awardee of the funds, which will be the buyer (in case of refund) or the seller (in case of the payment going through)
- We expect that this deduction of fees from the payment amount will discourage bad actors from participating on either side because even a decision in their favour will mean that they get paid less than what they were due