>From a merchant perspective, I would want to provide the customer with the most streamlined checkout possible, which IMO would mean that if they don't have a payment type enabled I could make it easy to enable that in the checkout flow itself (for example: paypal sign up before login is the same flow, adding a credit card before storing it is the same flow). If I have to kick the customer off the checkout path it's going to reduce conversion, it's a last resort due to restrictions in the payment method onboarding. You cited Apple Pay as an example, I wouldn't use this as a good example of an ideal case from a merchant or customer perspective, requiring the customer to jump out to a separate application (or multiple) to enable it is really bad for checkout conversion and I'm sure this onboarding experience will be improved upon in the future once the pain is felt. I say this here because I see some reference to this polling mechanism in place of the ability to recommend payment apps in the payment UI. I think it may be valuable in addition to that but if it's an alternative to that I think it's worth understanding that from most merchants perspectives, having to provide a separate payment method enablement path from the normal checkout path is a deal breaker. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/159#issuecomment-232039369
Received on Tuesday, 12 July 2016 13:00:14 UTC