Re: [w3c/payment-handler] Support delegating collection of shipping address and other user data to Payment Handler (#337)

Passing the `paymentRequestIdentifier` into the `fireEvent()` method might confuse web developers into thinking that they can handle arbitrary Payment Requests, even those not going through their service worker. Let's provide the web developer with a context for the current payment in a self-contained object.

```javascript
registration.paymentManager.paymentRequestEvent
.then((evt) => {
  console.log('Firing the method change event for payment request ' +
      evt.paymentRequestId);
  evt.changePaymentMethod('https://bobpay.xyz', {billingAddress: {country: 'CA'}})
  .then(handleUpdateWith)
  .catch(handleError);
}).catch(handleError);
```
The `paymentRequestEvent` promise would be resolved only in the window that was opened via `PaymentRequestEvent.openWindow()` in the 

@romandev : This is similar to your idea of delegating the full payment lifecycle to the payment handler window, right? This would allow the payment handler window to respond to the Payment Request without looping back into the service worker:

```javascript
registration.paymentManager.paymentRequestEvent
.then((evt) => {
  console.log('Responding to payment request ' +
      evt.paymentRequestId);
  evt.respondWith({methodName: 'https://bobpay.xyz', details: {token: '123'}});
}).catch(handleError);
```

This design still allows for UI-less payment handler, which might be necessary for some use cases.

-- 
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/payment-handler/issues/337#issuecomment-484128759