I think there may be a middle ground here that doesn't force UAs to implement a dynamic UI that could become overly complex (in the user experience) because of dynamic inputs that could very well be completely optional (discount, VAT ID, etc), but still give the merchant the ability to request information that is required like email or phone. I propose that we could stay away from generic / dynamic inputs for the required fields and expand on ``requestEmail``, ``requestPhone``, etc for these, this will give UAs the flexibility to implement the best UI possible. But for optional data we allow a generic definition like the spec AdrianHB proposed, this could be in the form of something like ``additionalInfo`` that the UA doesn't have to make a primary part of the checkout flow but should make accessible in some secondary way (button/link that displays the generic inputs, could allow customizable label on this, for example "Additional Info" or if it's just a discount code it could be "Have a discount code?"). Please excuse the stream of text here, I believe @andrewpaliga was going to submit a more formal or polished proposal for this at some point. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/pull/65#issuecomment-215496035
Received on Thursday, 28 April 2016 17:05:20 UTC