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

I have to admit, I was originally in favor of option 2, but now that I see all of your comments, it seems that option 1 is the right way. It would be really great if we could follow the examples of the push, sync and notifications APIs for integrating with service workers.

@adrianhopebailie:
> I am also not convinced that we need a new `onpaymentrequest` event. Why is inspecting a message and deciding if it's a payment request a bad thing? Any `onmessage` logic will need to inspect the message to decide what to do next anyway.

Passing the payment requests as messages to `onmessage` would probably work just fine. There seems to be some precedent for adding explicit event handlers, though; The [Push API](https://w3c.github.io/push-api/#events) adds `onpush` and `onpushsubscriptionchange`, the [Notifications API](https://notifications.spec.whatwg.org/#service-worker-api) adds `onnotificationclick` and `onnotificationclose`, and the [Sync API](https://wicg.github.io/BackgroundSync/spec/#sync-event) adds `onsync`.

On the other hand, if the payment requests were [HTTP requests](https://w3c.github.io/webpayments-http-api/#generating-a-payment-response), we could use `onfetch`...

-- 
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-243060608