@jnormore +1 My take on this proposal is that it is in addition to the idea of recommended apps. It makes no sense on its own. So, the flow would be: * Merchant requests payment and specifies supported payment methods and optionally recommended payment apps for one or more of these. * Browser may also recommend apps (perhaps only if the merchant does not?) * If the user has no available apps then they select one of the recommended apps which is invoked in the same way as if it was being invoked to handle a payment except that the user is able to follow an enrollment/login path before authorizing the payment. * If the merchant doesn't want the user to be taken down an enrollment path: * They can "poll" the API to see if the user is able to handle the request with their registered apps. ALTERNATIVELY * The merchant sets a flag in the request that instructs the browser to not show any recommended apps to the user and to fail silently if there are no apps registered that can handle the payment request --- 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-232043634
Received on Tuesday, 12 July 2016 13:17:30 UTC