Re: [w3c/payment-request] Handling in-app shipping changes (Issue #1042)

Thanks for your responses @rsolomakhin and @ianbjacobs!

We are currently using `modifiers` to support this async communication with the partial address details ([full demo](https://github.com/dtjones404/payment-request-reproduction/blob/paymentmethodchange-demo/src/index.ts#L26-L46)):

```js
// running on the merchant domain
paymentRequest.onpaymentmethodchange = (event) => {
  const details = event.methodDetails;
  const { eventName, eventPayload } = details;

  const eventHandler = eventHandlers[eventName];

  async function getResponsePromise() {
    // merchant async function to validate and patch order updates via PayPal's Orders API
    const response = await eventHandler?.(eventPayload);
    return {
      modifiers: [
        {
          data: { response },
          supportedMethods: paymentURL,
        },
      ],
    };
  }

  event.updateWith(getResponsePromise());
};
```

This allows the merchant to make an async API call on their end to validate the address, confirm they can ship to it, and update the order to reflect any changes to the shipping cost.  We leverage `event.updateWith` to communicate to the payment app that the async work is complete, and whether the change is approved or rejected by the merchant.  For us, we like modifiers as it solves our use case to pass arbitrary data through the `PaymentRequest` API.  We see modifiers as a convenient low-level abstraction for the `PaymentRequest` API that can support many use cases because it is not overly prescriptive and does not enforce any shape on the data being passed.

Is this a valid use case for keeping modifiers as part of the spec?

We are open to switching to `onshippingaddresschange` and `onshippingoptionchange`, but we wanted to explain more about our use case first.  PayPal's [Orders API](https://developer.paypal.com/docs/api/orders/v2/#orders_get!c=200&path=status&t=response) is the source of truth for an order as it is progresses through its lifecycle (unapproved, patch updates, buyer approval, transaction complete).  It is redundant for us to store the payment information in the `PaymentRequest` details as well as on the server.  Due to this, we use a dummy `PaymentRequest` [details](https://developer.mozilla.org/en-US/docs/Web/API/PaymentRequest/PaymentRequest#details) object, since it is not the source of truth for our transaction.  Also, we have specific address requirements, for example we are not allowed to share address line number in the browser, since we consider that to be PII data, so it may be problematic for us if `PaymentRequest` is also enforcing a specific address schema.  It's important for PayPal to own the address form as part of our payment UI, and we do not want the browser to add friction to the address collection process by prompting the user for permission to share address details.

Are there any docs or demos you can share with `PaymentRequestEvent.changeShippingAddress`?  It's been difficult putting together a demo using those events since they're deprecated in the public docs.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/1042#issuecomment-2580803819
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/issues/1042/2580803819@github.com>