Re: [Bitcoin-development] BIP70: Canceling Payments

2014-02-03 Thread Christophe Biocca
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 useless.

The unhappy path scenario with Payment Requests (customer paid, but
for whatever reason that payment is no longer valid) can be simply
solved in 1 of 2 ways:

If the merchant realizes the mistake, they can refund the money.
If the customer realizes the problem, they can contact the merchant,
provide the signed request, and ask the merchant to return the funds.

What isn't covered?

On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth t...@go-taxi.biz wrote:
 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

 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.
 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: Canceling Payments

2014-02-03 Thread Tim Tuxworth Founder Go-taxi.biz
Is BIP70 limited to http only?

What about face to face scenarios, or realtime like ticket sales or gambling, 
and socket and/or bluetooth type connections?

Tim Tuxworth
Founder Go-Taxi.biz

div Original message /divdivFrom: Christophe Biocca 
christophe.bio...@gmail.com /divdivDate:2014/02/03  10:49 AM  (GMT-08:00) 
/divdivTo: Tim Tuxworth t...@go-taxi.biz /divdivCc: 
bitcoin-development@lists.sourceforge.net /divdivSubject: Re: 
[Bitcoin-development] BIP70: Canceling Payments /divdiv
/divOver 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 useless.

The unhappy path scenario with Payment Requests (customer paid, but
for whatever reason that payment is no longer valid) can be simply
solved in 1 of 2 ways:

If the merchant realizes the mistake, they can refund the money.
If the customer realizes the problem, they can contact the merchant,
provide the signed request, and ask the merchant to return the funds.

What isn't covered?

On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth t...@go-taxi.biz wrote:
 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

 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.
 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development