“Leverage smart contracts in the world of UPI to reduce occurrence of scams”

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 – 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 –

Note: Scammer = Seller = Receiver of money

1. This approach is driven from the buyer side. 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“
2. Buyer sends the link to this smart contract to the seller, who can view that the funds have been loaded
3. Seller confirms “acceptance” of the order and the expected timelines by signing the transaction with an “intent to deliver” label along
4. Seller then delivers on the goods/services as promised to the buyer, and signs the transaction with a “confirmation of goods/services delivered” label and also captures proof of delivery either in the form of photos or a physical signature
5. At time of delivery, buyer confirms “receipt of goods/services” and signs the transaction with a “confirmation of goods/services received” label
6. Signing the transaction executes the smart contract, and the funds are instantly transferred from the smart contract to the seller’s account.

Note: The final signature on the transaction executes the entire smart contract, and the funds are instantly transferred from the smart contract to the seller’s account.

Actor	Activity	Action	Label
Buyer	load money into smart contract using UPI	sign –> load INR	“offer to pay” + “agreed upon time window“
Buyer	send link to smart contract to seller	share contract
Seller	confirm acceptance of order	sign –> accept contract	“intent to deliver” + “expected timelines“
Seller	deliver goods/services	sign –> confirm delivery made	“confirmation of goods/services delivered“
Buyer	receives goods/services	sign –> confirm delivery received	“confirmation of goods/services received“

This mitigates the problem of bad actors in a couple of different ways –

• Bad actor on buyer side = 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

• Bad actor on seller side = No intention of making the actual delivery
  • The problem of asynchronous delivery can be tackled by using timelocks that automate the flow of funds away from buyer towards the seller, with checks and balances along the way.
  • To make this process a little more robust in terms of showing serious intent, one can use timelocks for managing the automated flow of transactions –
    • Funds loaded by buyer into smart contract under “offer to buy” are locked for a period of 1 hour during which the seller has to sign with “intent to deliver“.
  • Once seller signs “intent to deliver“, the “agreed upon time window” kicks in, and if seller does not deliver within time, then the funds are automatically released back to the buyer.
  • However, if seller signs the transaction with “confirmation of goods/services delivered” within the agreed timeline, then buyer has 1 hour to contest the same.
  • In case the buyer misses that window to contest, funds are automatically transferred from the smart contract to the seller.
  • In case the buyer has not received the products/services, and they sign transaction as “no confirmation of goods/services delivered“ within the 1 hour window, then money is blocked and neither buyer nor seller have access to the funds for 72 hours.
  • At this point, the matter is also automatically sent to an offline 3rd-party adjudicator who has to investigate and take a decision based on evidence that is to be provided by both sides.
  • Based on the decision taken by the adjudicator, the money is automatically transferred over to the right recipient (after deduction of adjudicator fees).
  • Note: Since this will mean that not 100% of the transaction value will be returned to either side, it is expected that both buyers and sellers will tend to be good actors in every transaction.

To recap, it would not be fair (or practical) to expect that buyers should never have to make any sort of financial transaction (or gesture) to prove their intent, and that sellers should be expected to incur cost of rejection/return as a cost of doing business.