Re: [w3c/webpayments-payment-apps-api] Thoughts on the current spec (#34)

> The way to register SWs is through the navigator.serviceWorker.register() function. This is the register() function that I have in mind here.

👍 

> However, the browser can trigger this registration logic from a payment UI as well.

:+1: - so both will execute the registration logic of the service worker. i.e. There is no situation where a user uses a Payment App but that app is not registrered.

> Since this is relevant to push payments only, we should discuss it in the push payment spec, right?

Well, the point is that pretty much all payments done from a third-party app are likely to be push from the perspective of the website. Said differently, payment methods that are handled by 3rd party apps are likely to process the payment itself before a response is returned to the website.

There isn't actually a "push payments spec" but we are putting more focus on how we can address push payments and if there is a need for changes to either the payment request, payment apps or payment method identifiers specs that are needed.

I think an easy way to allow the website to track the state of a payment request is to give each new request a UUID that is returned to the website through an event when the user selects a third-party payment app. The same UUID should be passed to the app in the request and can be used by the app and the website to reconcile the request with later events such as out of band communications between the app and the website's servers.

-- 
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/34#issuecomment-246367256