Should we validate nonsense payer error properties?

[marcoscaceres]

If we have a payment request that has option: {requestPayerEmail: false}, then what should we do if the merchant asks to correct something that was not requested, like

response.retry({payer: {email: "Lol, I never asked for your email."} })

Right now, the spec just says to ignore that. Should we maybe throw or just continue to ignore. The above also applies to some cases of .updateWith() (e.g., flagging shipping address errors when no shipping address was requested).

cc @aestes, @rsolomakhin, @romandev.

[romandev]

I thought it would be better to throw an exception to give developers useful information and predictable code but my thought was changed after your comment[1].

I'm not sure but I think it's not different with passing undefined dictionary members.

// The payee is not PaymentValidationErrors's member.
// So, we just ignore it.
response.retry({ payee: { email: "Hello" }});

[1] https://github.com/w3c/payment-request/pull/768#pullrequestreview-151646708

[marcoscaceres]

I thought it would be better to throw an exception to give developers useful information and predictable code but my thought was changed after your comment [1].

I'm open to revising this assumption, because the merchant might be confused as to why the user is not fixing something the user can't fix (e.g., "fix your email!")... and the user might be wondering why retrying the payment is failing ("I can't fix my email, you dummy! you never asked for it so the browser doesn't let me!").

[rsolomakhin]

I would prefer that UA either console.warn() or throw an exception. A web developer would have a hard time correcting their mistakes if the UA silently ignores them.

[aestes]

A warning seems good, in particular for shipping address errors. I sorta anticipate confusion around the requirement that merchants must omit all shipping options for address errors to take effect.