基于 Web 的支付处理程序 API

如果基于 Web 的支付处理程序支持 CanMakePaymentEvent，用户代理可使用它协助筛选可用的基于 Web 的支付处理程序。

实现可以对开发者响应 CanMakePaymentEvent施加超时时间。如果超时到期，则实现的行为等同于调用了 respondWith() 且参数为 false。

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler oncanmakepayment;
};

oncanmakepayment 属性是一个事件处理程序，其对应的事件处理程序事件类型为 "canmakepayment"。

CanMakePaymentEvent 用作一个信号，指示基于 Web 的支付处理程序是否能够响应支付请求。

WebIDL[Exposed=ServiceWorker]
interface CanMakePaymentEvent : ExtendableEvent {
  constructor(DOMString type);
  undefined respondWith(Promise<boolean> canMakePaymentResponse);
};

此方法由基于 Web 的支付处理程序用作一个信号，指示其是否能够响应支付请求。

通过 PaymentRequest 收到请求后，用户代理必须（MUST） 运行以下步骤：

如果用户代理的设置禁止使用 CanMakePaymentEvent（例如在私密浏览模式下），则终止这些步骤。
令 registration 为一个 ServiceWorkerRegistration。
如果未找到 registration，则终止这些步骤。
使用触发功能事件 "canmakepayment"，并在 registration 上使用 CanMakePaymentEvent。

本节为非规范性内容。

此示例展示如何编写一个监听 CanMakePaymentEvent 的 service worker。当收到 CanMakePaymentEvent 时，service worker 始终返回 true。

示例 1：处理 CanMakePaymentEvent

self.addEventListener("canmakepayment", function(e) {
  e.respondWith(new Promise(function(resolve, reject) {
    resolve(true);
  }));
});

给定一个 PaymentMethodData 和一个在支付方式标识符上匹配的基于 Web 的支付处理程序，如果该支付处理程序可用于支付，则此算法返回 true：

令 methodName 为支付方式标识符字符串，由 PaymentMethodData 中指定。
令 methodData 为 PaymentMethodData 的支付方式专有数据。
令 paymentHandlerOrigin 为该基于 Web 的支付处理程序的 ServiceWorkerRegistration 作用域 URL 的源。
令 paymentMethodManifest 为 methodName 的已获取并已解析的支付方式清单。
如果 methodName 是一个基于 URL 的支付方式标识符，且 paymentMethodManifest 中 "*" 字符串已被 support origins 支持，则返回 true。
否则，如果 methodName 这个基于 URL 的支付方式标识符与 paymentHandlerOrigin 有相同的源，则在该基于 Web 的支付处理程序中触发 CanMakePaymentEvent 并返回其结果。
否则，如果 paymentMethodManifest 的支持源是一个有序源(origin) 集合，并包含 paymentHandlerOrigin，则在该基于 Web 的支付处理程序中触发 CanMakePaymentEvent 并返回其结果。
否则，返回 false。

用户选择某个基于 Web 的支付处理程序后，用户代理会触发 PaymentRequestEvent，并使用随后得到的 PaymentHandlerResponse 为 [payment-request] 创建 PaymentResponse。

Issue 117：支持将 Abort() 委托给支付处理程序

Payment Request API 支持将终止操作的管理责任委托给支付应用。目前有一个提案，计划在 Web-based Payment Handler 接口中增加一个 paymentRequestAborted 事件。该事件将拥有一个 respondWith 方法，接受一个布尔参数，用于指示 paymentRequest 是否已被成功中止。

本规范扩展了 ServiceWorkerGlobalScope 接口。

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler onpaymentrequest;
};

onpaymentrequest 属性是一个事件处理程序，其对应的事件处理程序事件类型为 PaymentRequestEvent。

PaymentRequestDetailsUpdate 包含更新后的总金额（可选包括修饰符和配送选项）以及由于用户在基于 Web 的支付处理程序中选择支付方式、收货地址或配送选项可能导致的错误信息。

WebIDLdictionary PaymentRequestDetailsUpdate {
  DOMString error;
  PaymentCurrencyAmount total;
  sequence<PaymentDetailsModifier> modifiers;
  sequence<PaymentShippingOption> shippingOptions;
  object paymentMethodErrors;
  AddressErrors shippingAddressErrors;
};

一个人类可读的字符串，用于说明为什么用户选择的基于 Web 的支付方式、收货地址或配送选项无法使用。

基于变更后的支付方法、收货地址或配送选项而更新的总额。例如，总额可能因用户所选支付方法的账单地址改变了增值税（VAT）而变化；或者因用户所选/提供的配送选项/地址改变了配送费用而变化。

基于变更后的支付方法、收货地址或配送选项而更新的修饰符。例如，如果根据账单或收货地址总体总额增加了 €1.00，则每个修饰符中指定的总额也应增加 €1.00。

基于变更后的收货地址而更新的 shippingOptions。例如，对于用户提供的国家/地区，加急配送可能更昂贵或不可用。

支付方法的校验错误（如有）。

收货地址的校验错误（如有）。

PaymentRequestEvent 表示在用户选择之后，支付处理程序可用的数据和方法。用户代理会将 PaymentRequest 中可用数据的一个子集传递给支付处理程序。

WebIDL[Exposed=ServiceWorker]
interface PaymentRequestEvent : ExtendableEvent {
  constructor(DOMString type, optional PaymentRequestEventInit eventInitDict = {});
  readonly attribute USVString topOrigin;
  readonly attribute USVString paymentRequestOrigin;
  readonly attribute DOMString paymentRequestId;
  readonly attribute FrozenArray<PaymentMethodData> methodData;
  readonly attribute object total;
  readonly attribute FrozenArray<PaymentDetailsModifier> modifiers;
  readonly attribute object? paymentOptions;
  readonly attribute FrozenArray<PaymentShippingOption>? shippingOptions;
  Promise<WindowClient?> openWindow(USVString url);
  Promise<PaymentRequestDetailsUpdate?> changePaymentMethod(DOMString methodName, optional object? methodDetails = null);
  Promise<PaymentRequestDetailsUpdate?> changeShippingAddress(optional AddressInit shippingAddress = {});
  Promise<PaymentRequestDetailsUpdate?> changeShippingOption(DOMString shippingOption);
  undefined respondWith(Promise<PaymentHandlerResponse> handlerResponsePromise);
};

返回一个字符串，指示顶层收款方网页的来源（origin）。此属性由处理 PaymentRequestEvent进行初始化。

返回一个字符串，指示 PaymentRequest 被初始化的来源。当 PaymentRequest 在 topOrigin 中初始化时，这两个属性具有相同的值；否则二者不同。例如，当 PaymentRequest 在一个来源不同于 topOrigin 的 iframe 中初始化时，此属性值为该 iframe 的来源。此属性由处理 PaymentRequestEvent进行初始化。

获取时，paymentRequestId 属性返回与此 PaymentRequestEvent 对应的 PaymentRequest 的 [[details]].id。

此属性包含若干 PaymentMethodData 字典，包含网站可接受的支付方法标识符以及任何相关的特定支付方法数据。它由 PaymentRequest 使用下文定义的方法数据填充算法进行填充。

此属性表示请求支付的总金额。其类型为 PaymentCurrencyAmount 字典（定义见 [payment-request]），并使用在实例化相应 PaymentRequest 对象时所提供的 total 字段的副本进行初始化。

此 PaymentDetailsModifier 字典序列包含针对特定支付方法标识符的修饰符（例如，如果基于每种支付方法，支付金额或货币类型有所不同）。它由 PaymentRequest 使用下文定义的修饰符填充算法进行填充。

相应 PaymentRequest 中 PaymentOptions 的取值。仅当请求收货地址和/或付款人联系信息的任意子集时可用。

相应 PaymentDetailsInit 字典中的 ShippingOptions 的取值。（PaymentDetailsInit 继承了 PaymentDetailsBase 的 ShippingOptions）。仅当请求收货地址时可用。

此方法由基于 Web 的支付处理程序用于向用户展示一个窗口。调用该方法时，会运行打开窗口算法。

此方法由基于 Web 的支付处理程序用于根据付款方式详情（如账单地址）获取更新后的总金额。调用该方法时，会运行更改支付方式算法。

此方法由基于 Web 的支付处理程序用于根据 shippingAddress 获取更新后的支付详情。调用该方法时，会运行更改支付详情算法。

此方法由基于 Web 的支付处理程序用于根据 shippingOption 标识符获取更新后的支付详情。调用该方法时，会运行更改支付详情算法。

此方法由基于 Web 的支付处理程序在支付成功完成时，提供 PaymentHandlerResponse。调用该方法时，会以 event 和 handlerResponsePromise 为参数，运行响应 PaymentRequest 算法。

Issue 123: 与支付应用共享用户数据？

是否应在用户明确同意的情况下，将存储在用户代理中的用户数据提供给支付应用？支付应用可以在安装时或首次被调用时请求该权限。

WebIDLdictionary PaymentRequestEventInit : ExtendableEventInit {
  USVString topOrigin;
  USVString paymentRequestOrigin;
  DOMString paymentRequestId;
  sequence<PaymentMethodData> methodData;
  PaymentCurrencyAmount total;
  sequence<PaymentDetailsModifier> modifiers;
  PaymentOptions paymentOptions;
  sequence<PaymentShippingOption> shippingOptions;
};

topOrigin、 paymentRequestOrigin、 paymentRequestId、 methodData、 total、 modifiers、 paymentOptions 与 shippingOptions 成员与 PaymentRequestEvent 中的相应定义共享定义。

为初始化 methodData 的值，用户代理 必须（MUST）执行以下步骤或等效步骤：

令 registeredMethods 为已调用的基于 Web 的支付处理程序所注册的支付方式标识符集合。
创建一个新的空的 Sequence。
将 dataList 设为新创建的 Sequence。
对于相应支付请求中的 PaymentRequest@[[methodData]] 中的每个条目，执行以下步骤：
1. 将 inData 设为当前条目。
2. 将 commonMethods 设为 inData.supportedMethods 与 registeredMethods 的交集。
3. 如果 commonMethods 为空，跳过余下子步骤并继续下一个条目（如果有）。
4. 创建一个新的 PaymentMethodData 对象。
5. 将 outData 设为新创建的 PaymentMethodData。
6. 将 outData.supportedMethods 设为包含 commonMethods 成员的列表。
7. 将 outData.data 设为 inData.data 的副本。
8. 将 outData 追加到 dataList。
将 methodData 设为 dataList。

为初始化 modifiers 的值，用户代理 必须（MUST）执行以下步骤或等效步骤：

令 registeredMethods 为已调用的基于 Web 的支付处理程序所注册的支付方式标识符集合。
创建一个新的空的 Sequence。
将 modifierList 设为新创建的 Sequence。
对于相应支付请求中的 PaymentRequest@[[paymentDetails]].modifiers 中的每个条目，执行以下步骤：
1. 将 inModifier 设为当前条目。
2. 将 commonMethods 设为 inModifier.supportedMethods 与 registeredMethods 的交集。
3. 如果 commonMethods 为空，跳过余下子步骤并继续下一个条目（如果有）。
4. 创建一个新的 PaymentDetailsModifier 对象。
5. 将 outModifier 设为新创建的 PaymentDetailsModifier。
6. 将 outModifier.supportedMethods 设为包含 commonMethods 成员的列表。
7. 将 outModifier.total 设为 inModifier.total 的副本。
8. 将 outModifier 追加到 modifierList。
将 modifiers 设为 modifierList。

PaymentRequestEvent 的实例会使用下表中的内部槽进行创建：

内部槽	默认值	描述（非规范性）
[[windowClient]]	null	当前活跃的 WindowClient。如果基于 Web 的支付处理程序当前正在向用户展示窗口，则会设置此项。否则为 null。
[[respondWithCalled]]	false	YAHO

当通过 PaymentRequest，利用 PaymentRequest.show() 接收到付款请求，并且用户随后选择了某个基于 Web 的支付处理程序时，用户代理必须执行以下步骤：

令 registration 为用户所选择的基于 Web 的支付处理程序所对应的 ServiceWorkerRegistration。
如果未找到 registration，则拒绝由 Promise （由 PaymentRequest.show() 创建）并返回 "InvalidStateError" DOMException，并终止这些步骤。
在 registration 上，使用触发功能事件 "paymentrequest"，并以 PaymentRequestEvent 及如下属性：

topOrigin

付款网页顶层页面的 origin 的序列化。

paymentRequestOrigin

初始化 PaymentRequest 的上下文 origin 的序列化。

methodData

执行方法数据填充算法的结果。

modifiers

执行修饰符填充算法的结果。

total

来自对应 PaymentDetailsInit 的总金额字段的副本。

paymentRequestId

\[\[details\]\].id ，取自对应 PaymentRequest。

paymentOptions

传递给对应 PaymentRequest 构造函数的 paymentOptions 字典的副本。

shippingOptions

来自对应 PaymentDetailsInit 的 shippingOptions 字段副本。

然后在并行中，以 dispatchedEvent 执行以下步骤：
1. 等待 dispatchedEvent 的所有扩展生命周期 promise 均已解决。
2. 如果基于 Web 的支付处理程序未提供 PaymentHandlerResponse，则拒绝由 Promise （由 PaymentRequest.show() 创建）并返回 "OperationError" DOMException。

被调用的基于 Web 的支付处理程序可能需要，也可能不需要，显示自身相关信息或请求用户输入。基于 Web 的支付处理程序可能显示的情况示例包括：

基于 Web 的支付处理程序为用户打开一个窗口，以输入授权码。
基于 Web 的支付处理程序打开一个窗口，让用户可以直接用此前配置的默认信息简便地确认支付。
在某次会话中首次选用该支付处理程序支付时，会打开窗口。之后在同一会话中，如有配置，基于 Web 的支付处理程序可无需打开窗口和用户交互直接完成操作。

若基于 Web 的支付处理程序需要可视化展示和用户交互，可调用 openWindow() 向用户展示页面。

注

由于用户代理知晓该方法与 PaymentRequestEvent 是相关联的，应当以合理且不造成用户困惑的方式渲染窗口。最终生成的窗口 client 会绑定到发起 PaymentRequest 的标签页/窗口。单个基于 Web 的支付处理程序不应允许通过该方法打开多个 client 窗口。

Issue 115：打开窗口算法

该算法类似于 Service Workers 规范中的打开窗口算法。

Issue 115：打开窗口算法

我们是否应该直接引用 Service Workers 规范而不是把其步骤复制过来？

令 event 为此 PaymentRequestEvent。
如果 event 的 isTrusted 属性为 false，则返回以 "InvalidStateError" DOMException 拒绝的 Promise。
令 request 为触发此 PaymentRequestEvent 的 PaymentRequest。
令 url 为解析 url 参数的结果。
如果 url 解析抛出异常，则返回以该异常拒绝的 Promise。
若 url 为 about:blank，则返回以 TypeError 拒绝的 Promise。
如果 url 的 origin 与与该基于 Web 的支付处理程序相关联的 service worker 的 origin 不同，则返回以 null 解决的 Promise。
令 promise 为新的 Promise。
返回 promise，并在并行中执行后续步骤：
若 event.[[windowClient]] 不为 null，则：
1. 若 event.[[windowClient]].visibilityState 不为 "unloaded"，用 "InvalidStateError" DOMException 拒绝 promise，并终止这些步骤。
令 newContext 为新的顶级浏览上下文。
用启用异常和启用替换的模式导航 newContext 到 url。
如果导航抛出异常，则以该异常拒绝 promise 并终止这些步骤。
若 newContext 的 origin 与与该基于 Web 的支付处理程序相关联的 service worker client 的 origin 不同，则：
1. 用 null 解决 promise。
2. 终止这些步骤。
令 client 为以 newContext 作为参数，运行创建窗口 client 算法的结果。
设置 event.[[windowClient]] 为 client。
用 client 解决 promise。

本节为非规范性内容。

此示例展示如何编写一个监听 PaymentRequestEvent 的 service worker。当接收到 PaymentRequestEvent 时，service worker 会打开一个窗口与用户交互。

示例 2：处理 PaymentRequestEvent

async function getPaymentResponseFromWindow() {
  return new Promise((resolve, reject) => {
    self.addEventListener("message", listener = e => {
      self.removeEventListener("message", listener);
      if (!e.data || !e.data.methodName) {
        reject();
        return;
      }
      resolve(e.data);
    });
  });
}

self.addEventListener("paymentrequest", e => {
  e.respondWith((async() => {
    // Open a new window for providing payment UI to user.
    const windowClient = await e.openWindow("payment_ui.html");

    // Send data to the opened window.
    windowClient.postMessage({
      total: e.total,
      modifiers: e.modifiers
    });

    // Wait for a payment response from the opened window.
    return await getPaymentResponseFromWindow();
  })());
});

使用上述简单方案，加载到基于 Web 的支付处理程序窗口的一个基础 HTML 页面可能如下所示：

示例 3：简单的支付处理程序窗口

<form id="form">
<table>
  <tr><th>Cardholder Name:</th><td><input name="cardholderName"></td></tr>
  <tr><th>Card Number:</th><td><input name="cardNumber"></td></tr>
  <tr><th>Expiration Month:</th><td><input name="expiryMonth"></td></tr>
  <tr><th>Expiration Year:</th><td><input name="expiryYear"></td></tr>
  <tr><th>Security Code:</th><td><input name="cardSecurityCode"></td></tr>
  <tr><th></th><td><input type="submit" value="Pay"></td></tr>
</table>
</form>

<script>
navigator.serviceWorker.addEventListener("message", e => {
  /* Note: message sent from payment app is available in e.data */
});

document.getElementById("form").addEventListener("submit", e => {
  const details = {};
  ["cardholderName", "cardNumber", "expiryMonth", "expiryYear", "cardSecurityCode"]
  .forEach(field => {
    details[field] = form.elements[field].value;
  });

  const paymentAppResponse = {
    methodName: "https://example.com/pay",
    details
  };

  navigator.serviceWorker.controller.postMessage(paymentAppResponse);
  window.close();
});
</script>

PaymentHandlerResponse 使用以下字典进行传达：

WebIDLdictionary PaymentHandlerResponse {
DOMString methodName;
object details;
DOMString? payerName;
DOMString? payerEmail;
DOMString? payerPhone;
AddressInit shippingAddress;
DOMString? shippingOption;
};

用户为完成交易所选择的支付方法标识符，对应于该支付方法。

一个可 JSON 序列化的对象，提供一条由商户用于处理交易并判断资金转账是否成功的，支付方法专有消息。

用户代理通过对应 respondWith 函数所提供 Promise 的解决，从基于 Web 的支付处理程序处收到成功响应。应用需用包含支付响应的 PaymentHandlerResponse 实例来解决该 Promise。如遇用户取消或出错，应用可通过拒绝该 Promise 来表示失败。

如果该 Promise 被拒绝，则用户代理必须运行支付应用失败算法。该算法的具体细节留给各实现者决定。可接受的行为包括但不限于：

允许用户重试，可以使用同一个基于 Web 的支付处理程序，也可以换一个；
拒绝由 PaymentRequest.show() 创建的 Promise。

用户提供的付款人姓名。

用户提供的付款人电子邮件。

用户提供的付款人电话号码。

用户提供的收货地址。

用户所选配送选项的标识符。

当以 methodName 和 methodDetails 参数调用此算法时，用户代理MUST运行以下步骤：

以给定的 methodName 和 methodDetails 参数构造 PaymentMethodChangeEvent event，并运行 payment method changed algorithm。
如果 event 的 updateWith(detailsPromise) 未被运行，则返回 null。
如果 event 的 updateWith(detailsPromise) 抛出异常，则重新抛出该错误。
如果 event 的 updateWith(detailsPromise) 超时（可选），则抛出 "InvalidStateError" DOMException。
从 event.updateWith(detailsPromise) 中的 detailsPromise 构造并返回一个 PaymentRequestDetailsUpdate。

当以 shippingAddress 或 shippingOption 调用此算法时，用户代理MUST运行以下步骤：

使用更新后的详情（shippingAddress 或 shippingOption）构造 PaymentRequestUpdateEvent event，并运行 PaymentRequest updated algorithm。
如果 event 的 updateWith(detailsPromise) 未被运行，则返回 null。
如果 event 的 updateWith(detailsPromise) 抛出异常，则重新抛出该错误。
如果 event 的 updateWith(detailsPromise) 超时（可选），则抛出 "InvalidStateError" DOMException。
从 event.updateWith(detailsPromise) 中的 detailsPromise 构造并返回一个 PaymentRequestDetailsUpdate。

当以 event 和 handlerResponsePromise 参数调用此算法时，用户代理MUST运行以下步骤：

如果 event 的 isTrusted 为 false，则抛出 "InvalidStateError" DOMException 并中止这些步骤。
如果 event 的 dispatch flag 未设置，则抛出 "InvalidStateError" DOMException 并中止这些步骤。
如果 event 的 [[respondWithCalled]] 为 true，则抛出 "InvalidStateError" DOMException 并中止这些步骤。
将 event 的 [[respondWithCalled]] 设为 true。
设置 event 的 stop propagation flag 和 event 的 stop immediate propagation flag。
将 handlerResponsePromise 添加到 event 的 extend lifetime promises 中。
将 event 的 pending promises count 增加 1。
当被拒绝时（Upon rejection），针对 handlerResponsePromise：
1. 运行支付应用失败算法并中止这些步骤。
当被兑现时（Upon fulfillment），针对 handlerResponsePromise：
1. 令 handlerResponse 为将 value 转换为 IDL 值的结果，类型为 PaymentHandlerResponse。若此操作抛出异常，则运行支付应用失败算法并中止这些步骤。
2. 校验 handlerResponse 中所有必需成员是否存在且格式正确。
  1. 若 handlerResponse 的 methodName 不存在，或未设置为 event 的 methodData 中的某个值，则运行支付应用失败算法并中止这些步骤。
  2. 若 handlerResponse 的 details 不存在或不是可 JSON 序列化的，则运行支付应用失败算法并中止这些步骤。
  3. 令 shippingRequired 为关联的 PaymentRequest 的 requestShipping 取值，来自 paymentOptions。如果 shippingRequired 且 handlerResponse 的 shippingAddress 不存在，则运行支付应用失败算法并中止这些步骤。
  4. 如果 shippingRequired 且 handlerResponse 的 shippingOption 不存在，或未设置为来自 event 的 shippingOptions 中的某个配送选项标识符，则运行支付应用失败算法并中止这些步骤。
  5. 令 payerNameRequired 为关联的 PaymentRequest 的 requestPayerName 取值，来自 paymentOptions。如果 payerNameRequired 且 handlerResponse 的 payerName 不存在，则运行支付应用失败算法并中止这些步骤。
  6. 令 payerEmailRequired 为关联的 PaymentRequest 的 requestPayerEmail 取值，来自 paymentOptions。如果 payerEmailRequired 且 handlerResponse 的 payerEmail 不存在，则运行支付应用失败算法并中止这些步骤。
  7. 令 payerPhoneRequired 为关联的 PaymentRequest 的 requestPayerPhone 取值，来自 paymentOptions。如果 payerPhoneRequired 且 handlerResponse 的 payerPhone 不存在，则运行支付应用失败算法并中止这些步骤。
3. 序列化 handlerResponse 的必需成员（methodName 与 details 始终必需；当 shippingRequired 为 true 时，shippingAddress 与 shippingOption 必需；当 payerNameRequired、payerEmailRequired、payerPhoneRequired 分别为 true 时，payerName、payerEmail、payerPhone 必需）：
  1. 对 handlerResponse 中的每个 member，令 serializeMember 为调用 StructuredSerialize 处理 handlerResponse.member 的结果。若有异常则重新抛出。
4. 用户代理MUST运行 [payment-request] 中定义的 user accepts the payment request algorithm，并以以下步骤替换其第 9-15 步或其等效步骤。
  1. 反序列化已序列化的成员：
    1. 对每个 serializeMember，令 member 为调用 StructuredDeserialize 处理 serializeMember 的结果。若有异常则重新抛出。
  2. 如果上述步骤中出现任何异常，则运行支付应用失败算法并中止这些步骤。
  3. 将 methodName 赋予关联 PaymentRequest 的 response.methodName。
  4. 将 details 赋予关联 PaymentReqeust 的 response.details。
  5. 若 shippingRequired，则将关联 PaymentReqeust 的 shippingAddress 属性设为 shippingAddress；否则设为 null。
  6. 若 shippingRequired，则将关联 PaymentReqeust 的 shippingOption 属性设为 shippingOption；否则设为 null。
  7. 若 payerNameRequired，则将关联 PaymentReqeust 的 payerName 属性设为 payerName；否则设为 null。
  8. 若 payerEmailRequired，则将关联 PaymentReqeust 的 payerEmail 属性设为 payerEmail；否则设为 null。
  9. 若 payerPhoneRequired，则将关联 PaymentReqeust 的 payerPhone 属性设为 payerPhone；否则设为 null。
当被兑现（Upon fulfillment）或当被拒绝（upon rejection） handlerResponsePromise 时，将一个微任务排入队列以执行以下步骤：
1. 将 event 的 pending promises count 减一。
2. 令 registration 为 this 的相关全局对象所关联的 service worker 的 containing service worker registration。
3. 如果 registration 不为 null，则以 registration 调用 Try Activate。

以下示例展示如何响应支付请求：

示例 4：发送支付响应

paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
  /* ... processing may occur here ... */
  accept({
    methodName: "https://example.com/pay",
    details: {
      cardHolderName:   "John Smith",
      cardNumber:       "1232343451234",
      expiryMonth:      "12",
      expiryYear :      "2020",
      cardSecurityCode: "123"
     },
    shippingAddress: {
      addressLine: [
        "1875 Explorer St #1000",
      ],
      city: "Reston",
      country: "US",
      dependentLocality: "",
      organization: "",
      phone: "+15555555555",
      postalCode: "20190",
      recipient: "John Smith",
      region: "VA",
      sortingCode: ""
    },
    shippingOption: "express",
    payerEmail: "john.smith@gmail.com",
  });
}));

注意

[payment-request] 定义了一个 ID，生态系统中的各方（包括支付应用提供方和收款方）可在网络或其他故障后使用其进行对账。

由于隐私问题，Web Payments 工作组从最初版本的 Payment Request API 中移除了对收货地址和账单地址的支持；参见 issue 842。为给仍继续支持此能力的实现提供文档，工作组现正恢复该功能，并期望同时解决隐私问题。在此过程中，工作组也可能基于其他 API 的演进（例如 Content Picker API）对 Payment Request API 进行更改。

该 API 不会共享用户已注册的基于 Web 的支付处理程序信息。只有在用户同意的情况下，来源(origin)的信息才会与收款方共享。
在用户选择某个支付处理程序之前，用户代理不应与任何基于 Web 的支付处理程序共享支付请求信息。
在支持 Web-based Payment Handler API 的浏览器中，当商户用基于 URL 的支付方式标识符创建 PaymentRequest 对象时，一个 CanMakePaymentEvent 会在已注册的基于 Web 的支付处理程序里被触发，这些处理程序来源于一组有限的来源：即支付方式清单(origin)以及其支持的来源。该事件会在用户选择该支付处理程序之前触发，但事件中不含任何触发源信息（即商户网站），因此不能直接用于用户跟踪。
我们意识到通过 CanMakePaymentEvent 存在时序攻击(timing attack)的风险：
- 商户网站通过后端通道（如 fetch API）向某个基于 Web 的支付处理程序 origin 发送通知，表示即将创建 PaymentRequest 对象；
- 随后商户网站创建 PaymentRequest，对应的 CanMakePaymentEvent 会在已安装的基于 Web 的支付处理程序中被触发；
- 该基于 Web 的支付处理程序联系其自身的 origin，服务器端试图关联这两次请求。
用户代理应允许用户禁用 CanMakePaymentEvent 的支持。
在支持 Web-based Payment Handler API 的浏览器中，只要需要，包括收货地址和付款人联系方式在内， CanMakePaymentEvent 会被触发给能提供全部商户请求信息的已注册基于 Web 的支付处理程序。

参见 Service Worker 安全注意事项
支付方式的安全性不在本规范范围之内，由支持这些支付方式的基于 Web 的支付处理程序自行处理。

支付方式的责任方通过支付方式清单授权支付应用。详情参见处理 CanMakePaymentEvent 算法。
用户代理没有义务提供存在安全风险的基于 Web 的支付处理程序。这些安全风险可能包括：
- 证书已过期、已吊销、自签名等情况。
- 混合内容
- 通过 HTTPS 可访问的页面跳转至非 HTTPS 页面。
- 支付处理程序在安全浏览数据库中被认定为恶意。
当某个基于 Web 的支付处理程序由于安全原因不可用时，用户代理应通过（如控制台消息）向开发者提供原因，也可以通知用户以帮助避免混淆。

支付方式清单授权特定来源发布某种支付方式的支付应用。当用户代理判断一个基于 Web 的支付处理程序是否与支付方式清单中列出的来源匹配时，用户代理会使用该支付处理程序 Service Worker 注册的 scope URL。

为缓解被劫持的收款方站点向其服务器提交欺诈或格式错误的支付方法数据（或相应的支付请求数据）的情形，收款方服务器应验证数据格式，并将数据与服务器上的权威信息进行关联，例如可接受的支付方法、总额、显示项以及收货地址。

当在“隐私浏览模式”下调用 Payment Request API 时，用户代理应在私有上下文中启动基于 Web 的支付处理程序。这一般会阻止站点访问任何先前存储的信息，这通常需要用户重新登录该来源或重新输入支付信息。
CanMakePaymentEvent 事件不应在隐私浏览模式下触发。用户代理应表现得如同 respondWith() 被以 false 调用一样。但我们也承认一个相关的风险：如果某个实体同时控制 Payment Request API 调用的来源和基于 Web 的支付处理程序的来源，则其可能能够推断用户处于隐私浏览模式。

基于 Web 的支付处理程序 API

摘要

本文档状态

1. 介绍

2. 概述

2.1 处理支付请求

2.2 与其他类型支付应用的关系

3. 注册

3.1 及时注册

4. 管理

4.1 对 ServiceWorkerRegistration 接口的扩展

4.2 PaymentManager 接口

4.2.1 userHint 属性

4.2.2 enableDelegations() 方法

4.3 PaymentDelegation 枚举

5. 可进行支付

5.1 对 ServiceWorkerGlobalScope 的扩展

5.1.1 oncanmakepayment 属性

5.2 CanMakePaymentEvent

5.2.1 respondWith() 方法

5.3 处理 CanMakePaymentEvent

5.4 处理 CanMakePaymentEvent 的示例

5.5 支付处理程序的筛选

6. 调用

6.1 对 ServiceWorkerGlobalScope 的扩展

6.1.1 onpaymentrequest 属性

6.2 PaymentRequestDetailsUpdate 字典

6.2.1 error 成员

6.2.2 total 成员

6.2.3 modifiers 成员

6.2.4 shippingOptions 成员

6.2.5 paymentMethodErrors 成员

6.2.6 shippingAddressErrors 成员

6.3 PaymentRequestEvent

6.3.1 topOrigin 属性

6.3.2 paymentRequestOrigin 属性

6.3.3 paymentRequestId 属性

6.3.4 methodData 属性

6.3.5 total 属性

6.3.6 modifiers 属性

6.3.7 paymentOptions 属性

6.3.8 shippingOptions 属性

6.3.9 openWindow() 方法

6.3.10 changePaymentMethod() 方法

6.3.11 changeShippingAddress() 方法

6.3.12 changeShippingOption() 方法

6.3.13 respondWith() 方法

6.3.14 PaymentRequestEventInit 字典

6.3.15 方法数据填充算法

6.3.16 修饰符填充算法

6.4 内部槽

6.5 处理 PaymentRequestEvent

7. 窗口

7.1 打开窗口算法

7.2 处理 PaymentRequestEvent 的示例

8. 响应

8.1 PaymentHandlerResponse 字典

8.1.1 methodName 属性

8.1.2 details 属性

8.1.3 payerName 属性

8.1.4 payerEmail 属性

8.1.5 payerPhone 属性

8.1.6 shippingAddress 属性

8.1.7 shippingOption 属性

8.2 变更支付方法算法

8.3 变更支付详情算法

8.4 响应 PaymentRequest 算法

9. 安全与隐私注意事项

9.1 地址

9.2 有关用户环境的信息

9.3 用户同意安装支付处理程序

9.4 付款前的用户同意

9.5 用户对跨源共享数据的认知

9.6 安全通信

9.7 授权的支付应用

9.8 支持的来源

9.9 数据验证

9.10 私密浏览模式

10. 支付处理程序显示注意事项

11. 依赖关系

4.1 对 `ServiceWorkerRegistration` 接口的扩展

4.2 `PaymentManager` 接口

4.2.1 `userHint` 属性

4.2.2 `enableDelegations()` 方法

4.3 `PaymentDelegation` 枚举

5.1 对 `ServiceWorkerGlobalScope` 的扩展

5.1.1 `oncanmakepayment` 属性

5.2 `CanMakePaymentEvent`

5.2.1 `respondWith()` 方法

5.4 处理 `CanMakePaymentEvent` 的示例

6.1 对 `ServiceWorkerGlobalScope` 的扩展

6.1.1 `onpaymentrequest` 属性

6.2 `PaymentRequestDetailsUpdate` 字典

6.2.1 `error` 成员

6.2.2 `total` 成员

6.2.3 `modifiers` 成员

6.2.4 `shippingOptions` 成员

6.2.5 `paymentMethodErrors` 成员

6.2.6 `shippingAddressErrors` 成员

6.3 `PaymentRequestEvent`

6.3.1 `topOrigin` 属性

6.3.2 `paymentRequestOrigin` 属性

6.3.3 `paymentRequestId` 属性

6.3.4 `methodData` 属性

6.3.5 `total` 属性

6.3.6 `modifiers` 属性

6.3.7 `paymentOptions` 属性

6.3.8 `shippingOptions` 属性

6.3.9 `openWindow()` 方法

6.3.10 `changePaymentMethod()` 方法

6.3.11 `changeShippingAddress()` 方法

6.3.12 `changeShippingOption()` 方法

6.3.13 `respondWith()` 方法

6.3.14 `PaymentRequestEventInit` 字典

7.2 处理 `PaymentRequestEvent` 的示例

8.1 `PaymentHandlerResponse` 字典

8.1.1 `methodName` 属性

8.1.2 `details` 属性

8.1.3 `payerName` 属性

8.1.4 `payerEmail` 属性

8.1.5 `payerPhone` 属性

8.1.6 `shippingAddress` 属性

8.1.7 `shippingOption` 属性