Suggestion for extension of JSON protocol.

[zhoujianfu]

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.

[zhoujianfu]

@chaintip 30 days

[shibe2]

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.

[zhoujianfu]

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 notifications@github.com 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 https://github.com/bitpay/jsonPaymentProtocol/issues/13#issuecomment-398810515, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5aIqFtsn2hwjUPdOyb0rQH4-SgkZ3uks5t-nZkgaJpZM4UpD7b .

[shibe2]

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.

[zhoujianfu]

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 notifications@github.com 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 https://github.com/bitpay/jsonPaymentProtocol/issues/13#issuecomment-398852337, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5aIqeu8GjsaWD0dpn8QR_nWScTGKj8ks5t-pWEgaJpZM4UpD7b .

[chaintip]

0 BCH| ~ 0.00 USD has now been tipped to this issue. To claim this bounty, get a pull request merged with @chaintip fixes #13 in the creation comment.

[monsterbitar]

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.