To @adrianhopebailie's dynamic data collection proposal, we would strongly support this, as he mentioned it would prevent us from using any solution to it's full potential without it due to the discount code issue. To expand on that, we have a platform of merchants who all have different data preferences or requirements for their customers to purchase something, VAT ID is another one that is common for B2B merchants and affects tax amount in a very dynamic way, this is not a payment app concern, it is between the merchant and their customer. All of this could be collected before initiating the payment request but that defeats the purpose of streamlining the checkout flow in order to reduce cart abandonment rates, as soon as you add another step to the checkout process (another decision for the customer to make, to continue or not) abandonment increases, not to mention the fragmented look and feel of the checkout experience with the merchant handling some while the user agent is handling the rest. There's also scenario of a single product page buy button, where there is no cart yet but the customer can save time by just hitting "Buy Now" while viewing the product details, the faster you can get the customer into the user agents checkout experience the better, jumping to another merchant hosted page just to ask for a discount code would be a bad experience for the customer. --- 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-212680229
Received on Thursday, 21 April 2016 01:17:28 UTC