t;
>
> Original message
> From: Christophe Biocca
> Date:2014/02/03 10:49 AM (GMT-08:00)
> To: Tim Tuxworth
> Cc: bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] BIP70: Canceling Payments
>
> Over http, the merchant doesn't h
: Tim Tuxworth Cc:
bitcoin-development@lists.sourceforge.net Subject: Re:
[Bitcoin-development] BIP70: Canceling Payments
Over http, the merchant doesn't have the ability to reach out to the
consumer's bitcoin wallet on their own. So sending "Cancel Payment
Request" to the use
- Original message
> From: Christophe Biocca
> Date:2014/02/03 10:49 AM (GMT-08:00)
> To: Tim Tuxworth
> Cc: bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] BIP70: Canceling Payments
>
> Over http, the merchant doesn't have the abil
Over http, the merchant doesn't have the ability to reach out to the
consumer's bitcoin wallet on their own. So sending "Cancel Payment
Request" to the user is impossible.
If the customer doesn't want to send, nothing ever needs to happen. So
sending a "Reject Payment Request" to the merchant is u
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
5 matches
Mail list logo
