* Re: [Bitcoin-development] BIP70: Canceling Payments
@ 2014-02-03 20:30 Tim Tuxworth Founder Go-taxi.biz
2014-02-03 20:37 ` Christophe Biocca
2014-02-03 21:25 ` Andreas Schildbach
0 siblings, 2 replies; 5+ messages in thread
From: Tim Tuxworth Founder Go-taxi.biz @ 2014-02-03 20:30 UTC (permalink / raw)
To: Christophe Biocca; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]
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 --------</div><div>From: Christophe Biocca <christophe.biocca@gmail•com> </div><div>Date:2014/02/03 10:49 AM (GMT-08:00) </div><div>To: Tim Tuxworth <tim@go-taxi•biz> </div><div>Cc: bitcoin-development@lists•sourceforge.net </div><div>Subject: Re: [Bitcoin-development] BIP70: Canceling Payments </div><div>
</div>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 <tim@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=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3211 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] BIP70: Canceling Payments
2014-02-03 20:30 [Bitcoin-development] BIP70: Canceling Payments Tim Tuxworth Founder Go-taxi.biz
@ 2014-02-03 20:37 ` Christophe Biocca
2014-02-03 21:25 ` Andreas Schildbach
1 sibling, 0 replies; 5+ messages in thread
From: Christophe Biocca @ 2014-02-03 20:37 UTC (permalink / raw)
To: Tim Tuxworth Founder Go-taxi.biz; +Cc: bitcoin-development
It's not limited to HTTP. I was pointing out that unsolicited
merchant-to-consumer messages don't work on HTTP (and a lot of other
situations), and so you can't add a need for it to the payment
protocol (since it wouldn't be usable in the majority of cases).
On Mon, Feb 3, 2014 at 3:30 PM, Tim Tuxworth Founder Go-taxi.biz
<tim@go-taxi•biz> wrote:
> 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
>
>
> -------- 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 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 <tim@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=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] BIP70: Canceling Payments
2014-02-03 20:30 [Bitcoin-development] BIP70: Canceling Payments Tim Tuxworth Founder Go-taxi.biz
2014-02-03 20:37 ` Christophe Biocca
@ 2014-02-03 21:25 ` Andreas Schildbach
1 sibling, 0 replies; 5+ messages in thread
From: Andreas Schildbach @ 2014-02-03 21:25 UTC (permalink / raw)
To: bitcoin-development
Have a look at my post "Payment Protocol for Face-to-face payments". In
short: I implemented BIP70 using combinations of either QR-code or NFC
plus Bluetooth. You can download a working preview app from:
https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
On 02/03/2014 09:30 PM, Tim Tuxworth Founder Go-taxi.biz wrote:
> 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
>
>
> -------- 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 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 <tim@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=121051231&iu=/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=121051231&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] BIP70: Canceling Payments
2014-02-03 18:08 Tim Tuxworth
@ 2014-02-03 18:49 ` Christophe Biocca
0 siblings, 0 replies; 5+ messages in thread
From: Christophe Biocca @ 2014-02-03 18:49 UTC (permalink / raw)
To: Tim Tuxworth; +Cc: bitcoin-development
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 <tim@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=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bitcoin-development] BIP70: Canceling Payments
@ 2014-02-03 18:08 Tim Tuxworth
2014-02-03 18:49 ` Christophe Biocca
0 siblings, 1 reply; 5+ messages in thread
From: Tim Tuxworth @ 2014-02-03 18:08 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-02-03 21:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-03 20:30 [Bitcoin-development] BIP70: Canceling Payments Tim Tuxworth Founder Go-taxi.biz
2014-02-03 20:37 ` Christophe Biocca
2014-02-03 21:25 ` Andreas Schildbach
-- strict thread matches above, loose matches on Subject: below --
2014-02-03 18:08 Tim Tuxworth
2014-02-03 18:49 ` Christophe Biocca
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox