Re: [w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

@rsolomakhin 

> Suppose a merchant website at https://shop.com calls PaymentRequest with a supported payment method of https://bobpay.xyz. The user has installed a Service Worker from https://alicepay.xyz that supports https://bobpay.xyz

Due to lack of experience I'm a little confused by this example. Can you give me something more real-world where the merchant, payment handler, & payment method are distinct?

The "primary key" of a service worker registration is its scope, which allows for multiple service worker registrations on a single origin. A single service worker registration can update its script URL, but its scope URL is fixed. Seems like the scope should be used to identify a payment app.

There's still no update model for manifests, so the more information you put in there, the more updating trouble you'll land in. You'll either have to live with out-of-date info, or request the manifest every time you need the info from it, and that'll slow things down. If this information was set using APIs in a service worker, its updating is in the control of the origin owner.

Is it useful to specify Android/iOS in that much detail? As far as I know, native apps can already hijack navigations, so can't they just hijack the payment process in a similar way? The spec could provide hooks for this, eg "If bobpay's native app is install, it can do what it wants as long as it returns <dataformat> to the next step".

-- 
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/33#issuecomment-245952004