Suggestion for extension of JSON protocol. #13
Comments
|
@chaintip 30 days |
|
|
1. I'd say the protocol's job should just be to request everything it
needs, and then it's up to the rest of the checkout process to verify it's
complete/valid. So a typical flow would be on the first page of a website
there's some product with a "buy it now with crypto" button that links to
like bitcoin:?r=https://bitpay.com/i/Q56iqy1fkmsxJotD336i8C .. if your
wallet doesn't support the protocol, or you send a shipping address to say
a country they don't ship to, or anything else is blank/wrong (apart from
the send amount/fee/address), the payment should still be accepted, and the
(bad/incomplete) data received still passed to the seller, who then can do
a sanity check on it and display a new page that asks the buyer to correct
anything deemed invalid. The buyer would of course have a big incentive to
do so, since they probably won't get what they paid for otherwise. And if
the buyer doesn't, the seller knows where to refund the payment to!
2. I don't think so, as a merchant myself, I always try my hardest to only
request the minimum info needed to process the transaction. More forms/data
always equals fewer completed orders! And with GDPR and what-not, storing
your customer's data is really more a liability. But there are some things
(typically email, maybe shipping address) merchants really do need to
complete the transaction, and it'd be an awesome experience if crypto could
provide an amazon-like checkout experience internet (and world)-wide!
…On Wed, Jun 20, 2018 at 9:20 AM shibe2 ***@***.***> wrote:
1. What should happen if the wallet does not support the extension?
2. This will encourage sellers to collect more information than they
actually need. Public discussion needed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5aIqFtsn2hwjUPdOyb0rQH4-SgkZ3uks5t-nZkgaJpZM4UpD7b>
.
|
|
|
1. You're right, that would be done better as part of the protocol! In
fact, I think it could fit into the current protocol pretty well. Here's
the existing application logic:
1. (Web) User selects preferred currency on invoice if multiple options
are available
2. (Client) Wallet obtains payment protocol uri
3. (Client) Fetches payment information from server
4. (Server) Verifies invoice exists and is still accepting payments,
responds with payment request
5. (Client) Validates payment request hash
6. (Client) Validates payment request signature
7. (Client) Generates a payment to match conditions on payment request
8. (Client) Submits proposed signed transaction to server
9. (Server) Validates invoice exists and is still accepting payments
10. (Server) Validates payment matches address, amount, and currency of
invoice and has a reasonable transaction fee.
11. (Server) Broadcasts payment to network and notifies client payment
was accepted.
12. (Client) If payment is accepted by server, wallet broadcasts payment
The change would just be in 4, the server includes something like "I want
shipping adddress" in the payment request. Then, when the client does 8
they'd also include responses to the metadata requested. Then in 10, the
server would also validate the metadata (along with the validation
currently being done)... and it's not mentioned in this flow, but I assume
if the validation fails an error message is sent back to the client to
display? So it'd just do that with something like "we don't ship to Canada"
or "shipping has increased your total to X." (along with a new payment
request for the client to respond to). So the client would be expected to
display the error(s) returned in step 10, and re-display the "pay now" page
with the new payment request I assume is currently sent back with the
errors. So pretty small change to the protocol really.. just standardizing
on a few metadata items in the payment request is all that's needed.
2. Agree to disagree I guess! I know I personally would never request more
than I need. And of course it's always up to the buyer if they want to
complete the purchase. I know both as a buyer and a seller I'd like this
extension. I think it's better to have this in the protocol... buyers and
sellers are free not to use it of course. I think if the technology is
possible and easy it should be done... otherwise it's a bit like saying
bitcoin should be illegal because it can be used in crimes.
…On Wed, Jun 20, 2018 at 11:33 AM shibe2 ***@***.***> wrote:
1. I think, it's always better to resolve all the important details of
the deal before making the payment. And the amount may depend on the
shipping address, for example. Better make this a separate request, and
then make the actual payment request with all the details known and
optionally signed by the merchant.
2. Typical business does want more data. Many countries do not have
effective privacy-protecting regulations. Where there are regulations, ways
around will be found and exploited. By adding data collection capabilities
to the protocol we make it less inconvenient and suspicious for customers,
so merchants will be more inclined to go for it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5aIqeu8GjsaWD0dpn8QR_nWScTGKj8ks5t-pWEgaJpZM4UpD7b>
.
|
|
|
|
I agree with this statement: "I think, it's always better to resolve all the important details of the deal before making the payment. And the amount may depend on the shipping address, for example." One way to accomplish this with the level of ease suggested here, is to allow users sign up and/or login with CashID: https://gitlab.com/cashid/protocol-specification Then, if their wallet supports both CashID and JsonPaymentProtocol, the process should be close to the level of smoothness desired. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think we could bring the bitcoin/bitcoin cash checkout experience up to paypal-levels of ease of use with one simple extension to this protocol.
Allow the merchant to specify in the Payment Request other metadata they would like from the user.
For example:
{{name}}, {{email}}, {{shipping_address}} (possibly broken into street, street2, city, state, postal_code, country), {{phone}}, {{photo_url}}, maybe even {{twitter_username}}, {{facebook_username}} or {{youtube_username}}.
Wallets implementing this could ask for (and then save) this information from the user, and then the next time they check out have it already pre-filled (with the option to edit). It would just be like:
Bitpay is requesting .01 BCH for "EFF Donation", they also are requesting your:
email: [zhoujianfu@test.com]
phone: [+1-234-567-8900]
[Make Payment!]
(Kind of like logging in with facebook and it says "this app would like to see your email and list of friends.")
If this extension is added, we've basically made it possible for shopping with crypto online AND in retail stores as easy as Amazon's one-click checkout.
The text was updated successfully, but these errors were encountered: