Tim Tuxworth [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-03 to 2014-02-03
💬 Posted a total of 1 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1pu0x2ud9reaxxtereheqwyzmuryfg34k9q6f5mefp4dfm2622apsxr6fsf

Profile Code

nprofile1qqsq78n9wxj3u7nr9u3umus8zpd7pjy5g6mzsdy6du5s6k5a4d99wsc4nqp67

Author Public Key

npub1pu0x2ud9reaxxtereheqwyzmuryfg34k9q6f5mefp4dfm2622apsxr6fsf

Show more details

Last Notes

2023-06-07 15:12:56

- reply

📅 Original date posted:2014-02-03
📝 Original message:The process described in BIP70 might be ok for a simple "happy path"
scenario, but what if things don't work so smoothly. I'm not talking
here about technical issues, but _very common_ business scenarios such as:
e.g. Merchant cancels request before payment is sent, such as when:-
- the merchant realizes that they charged the wrong amount
- the merchant realizes that they send the payment request to the wrong
customer
...
e.g. the Merchant or Customer decides to cancel the transaction after
the payment request is sent because:-
- the customer decides to pay by some other mechanism like cash or
credit/debit
- the customer doesn't have sufficient funds and decides not to purchase
- the customer changes their mind and decides not to purchase
...
It strikes me that a "Cancel Payment Request" message is required
and a "Reject Payment Request" may also be required (or maybe use the
same message for both).
Tim Tuxworth