Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support delegating collection of shipping address and other user data to Payment Handler #337

Open
danyao opened this Issue Apr 8, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@danyao
Copy link
Collaborator

danyao commented Apr 8, 2019

Today if a merchant requests shipping address or payer's contact information, the data collection is always handled by the browser. At last week's WPWG FTF in Foster City, there was interest among payment providers to be able to provide this information. Supporting this delegation can lead to better user experience because the payment app may have more accurate information than the browser.

We should support delegation for all fields that are currently requested via PaymentOptions: https://w3c.github.io/payment-request/#dom-paymentoptions

@rsolomakhin

This comment has been minimized.

Copy link
Collaborator

rsolomakhin commented Apr 9, 2019

A payment handler should specify their own capabilities.

registration.paymentManager.capabilities.set(
    ['requestShipping', 'requestPayerEmail'])
  .then(handleDoneSettingCapabilities)
  .catch(handleError);

This will allow user agents to re-use the keys of the PaymentOptions dictionary.

The PaymentRequestEvent should include readonly booleans for these options.

self.addEventListener('paymentrequest', evt => {
  if (evt.requestShipping) {
    doSomethingForShippingAddresses();
  }
});

A payment handler should also be able to fire the relevant events for the merchants.

registration.paymentManager.fireEvent(
    paymentRequestIdentifier, 'shippingaddresschange', {country: 'CA'})
  .then(handleUpdateWith)
  .catch(handleError);

User agents can reuse event names from Payment Request, such as shippingaddresschange.

The event firing method should be on the paymentManager object and keyed by the payment request identifier for ease of access by the payment handler window, where the user would be interacting with their shipping addresses and contact information. This is the pattern that we plan to use for responding to paymentrequest events in the future as well, so that the service worker process does not have to stay alive while the payment handler window is interactive.

@rsolomakhin

This comment has been minimized.

Copy link
Collaborator

rsolomakhin commented Apr 17, 2019

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.

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 service worker.

@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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.