search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request-1.1/
Other
482 stars 183 forks source link

Permissible data changes during a retry #933

Closed SECtim closed 3 years ago

SECtim commented 3 years ago

Hi! While reading up on @crowgames's findings about the retry mechanism (#882, #904), I was a bit confused by the following statement:

A user cannot switch payment handlers during retry. One can only change the things being retried (eg. new credit card expiry date).

Originally posted by @marcoscaceres in https://github.com/w3c/payment-request/issues/882#issuecomment-549197510

My understanding would be that "the things being retried" refers to the errorFields argument of retry(). This led me to the description of how a user agent must handle a retry() call. According to my understanding of that description, the user agent does not need to restrict modifications to the fields indicated by errorFields.

Did I overlook the respective instructions in the spec? If not, I think it would make sense to clarify the specifications in that aspect.

Cheers

marcoscaceres commented 3 years ago

According to my understanding of that description, the user agent does not need to restrict modifications to the fields indicated by errorFields.

That is correct... say the user wants to ship something to post code "1234", but the merchant says, "Post code 1234 is not valid". The user realizes that the entire address is wrong, and because of that, they decide to pay with an entirely different card. That's totally ok.

Did I overlook the respective instructions in the spec? If not, I think it would make sense to clarify the specifications in that aspect.

Just to make sure we are on the same page, is the example I gave above what we should try to clarify in the spec?

SECtim commented 3 years ago

Thanks for the response!

That is correct... say the user wants to ship something to post code "1234", but the merchant says, "Post code 1234 is not valid". The user realizes that the entire address is wrong, and because of that, they decide to pay with an entirely different card. That's totally ok.

Ok, thanks for the clarification - that's the way I understood the spec as well.

Just to make sure we are on the same page, is the example I gave above what we should try to clarify in the spec?

No, I think that's clear from the spec (although an example might be helpful in making that more explicit). I was just confused/unsure about my understanding due to your comment in #882 that "One can only change the things being retried".

I.e., my understanding of the spec is that the user agent may allow changes to, e.g., the credit card data even if the reason for the retry was an invalid shipping address. If that understanding is correct, we can close this issue :slightly_smiling_face: