docs(fee-bump): add more comments on how merchants are affected

Author: johnsBeharry

anatomy-psbt.md

@@ -22,14 +22,15 @@ A transaction can not only contain multiple payments but also other kinds of ope
 ### Send. Slowing down to manage expectations
 - Mpesa’s Hakikisha has a 5 min window for the transaction to get canceled. Bitcoin is more variable, as a transaction with a lower fee rate can take mins or hours to get a confirmation.
 - On-chain fees will continue to rise.
-- Should we encourange long to confirm on-chain transactions? Benefit is that the window of time to ammend a broadcasted transaction can be increased. 
+- Should we encourange long to confirm on-chain transactions? Benefit is that the window of time to ammend a broadcasted transaction using RBF can be increased.
 - Batching payments in a low fee transaction that takes longer to confirm but is cheaper?
   - Replace by Fee can allow you to add another payment to the batch, and also speed it up.
 - Scheduling transactions to be broadcasted when fee’s reach a certain amount?
 
 #### What are the implications in commerce?
 - https://github.com/btcpayserver/btcpayserver/issues/1330
 - Merchants like supermarkets and restaruants in Venezuela using "cryptobuyer" seem to accept/rely on 0 confirmation transactions.
+- Since there are varying times for on-chain transaction confirmations maybe merchants should also slow down, and only set the order as paid if they have full confirmation of a payment. Note: Instant payment and delivery may be solved if both sides adopt lightning payments in commerce.
 
 ### Receive
 - The appearance of faster payments can be achieved if wallets shows incoming mempool transactions.