Hi @jakearchibald, Section 4 intends to give the overall story (with some design rationale in there as well): https://w3c.github.io/webpayments-payment-apps-api/#model That's different from a concrete example or two, which I agree would be useful. We'll talk about that in the task force. Regarding your question: > how are things expected to work (or not work) when the payment provider "foo" is supported by a > shop, but it's not one of the stored "user agent-based payment app"s? I'd like to rewrite your question in the terms of the spec: what happens when a payee accepts the "foo" payment method but the user does not have any registered payment apps that support that payment method? A couple of things might happen: 1) The payee (merchant) might recommend some payment apps that the user could use. When the user selects one of these payment apps, it is registered with the user agent. 2) If there are no matching payment apps, then the merchant learns this within payment request API and can build a fallback checkout page. This process of calling the API then building a fallback page would happen prior to any user interface being displayed. 3) Payment request API also defines canMakePayment(), which gives the payee some additional tools to query the user's environment before calling show(). Does that help? Ian -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-273168055
Received on Tuesday, 17 January 2017 14:04:16 UTC