Re: [w3c/webpayments-payment-handler] Editorial changes for FPWD (#138)

adrianhopebailie commented on this pull request.



> @@ -362,13 +361,12 @@
         "PaymentManager.instruments">instruments</a> and <a data-lt=
         "PaymentManager.wallets">wallets</a>.
         </li>
-        <li>Payment apps make use of <a>service worker</a>s, starting with
-        registration of their capabilities with the user agent. A service
-        worker registration has zero or one <a>payment handler</a>. However, an
-        origin may implement a payment app with more than one service worker
-        registration.
+        <li>Payment apps make use of <a>service worker</a>s which must define a
+        <a>payment handler</a> to handle the <a>PaymentRequestEvent</a>s that
+        are raised by the user agent.

This is intentional. I think that as a developer it makes sense for this spec to start by telling me how I define a payment handler. After that it explains how I register the payment methods and capabilities I support in a way that will allow my payment handler to be invoked.

These are two separate things I must do as a developer so I don't want to try and bundle them together.

i.e. Start with the payment handling logic then the glue that links the payment request, the user choice and the event than my logic handles together.

I have added a note later on about multiplicity. I think the zero or one language is confusing. While it's technically possible to register a service worker and set a bunch of instruments and not register a payment handler that's a pointless exercise.

I'd be interested to hear from implementors as we begin fleshing out the algorithms whether it makes sense for the PaymentManager to be disabled if there is no event listener for the `onpaymentrequest` event.

-- 
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-handler/pull/138#discussion_r111896804