支払いリクエスト API

PaymentRequest は、提供された PaymentMethodData のシーケンス methodData（各 支払い方法 固有の data を含む場合がある）、 PaymentDetailsInit の details、および PaymentOptions の options を用いて構築されます。

PaymentRequest(methodData, details, options) コンストラクタは以下のように動作しなければなりません（MUST）:

1. this の 関連グローバルオブジェクト の 関連付けられた Document が、使用を許可された "payment" パーミッションを持たない場合、"SecurityError" DOMException を スローする。
2. リクエストの id を設定する:
   1. details.id が ない場合、details に id メンバーを追加し、その値を UUID [RFC4122] に設定する。
3. serializedMethodData を空のリストとする。
4. 支払い方法を処理する:
   1. methodData シーケンスの長さが 0 の場合、 少なくとも 1 つの 支払い方法 が必要である旨を（任意で）開発者に通知しつつ、 スロー で TypeError を投げる。
   2. seenPMIs を空の 集合 とする。
   3. methodData の各 paymentMethod について:
      1. paymentMethod.supportedMethods に対して 支払い方法識別子の検証 の手順を実行する。false が返された場合は RangeError 例外を投げる。任意で、支払い方法識別子が不正であることを開発者に通知してよい。
      2. pmi を、基本 URL パーサで paymentMethod.supportedMethods を解析した結果とする:
         1. 失敗した場合、pmi を paymentMethod.supportedMethods に設定する。
      3. もし seenPMIs が 含む pmi を持つなら、 RangeError の DOMException を投げ、 任意で、この 支払い方法識別子 が重複していることを開発者に通知する。
      4. 追加 により pmi を seenPMIs に加える。
      5. もし paymentMethod の data メンバーが存在しないなら、 serializedData を null とする。そうでなければ、 paymentMethod.data を JSON 文字列へ 直列化 した結果を serializedData とする。いかなる例外も再スローする。
      6. serializedData が null でなく、かつ paymentMethod.supportedMethods を定義する仕様が 追加データ型 を規定している場合:
         1. object を、JSON 解析 により serializedData をパースした結果とする。

         2. idl を、変換 によって object を 追加データ型 の IDL 値へ変換した結果とする。 いかなる例外も再スローする。

         3. 仕様に定義される paymentMethod.supportedMethods に対して、 可能であれば 支払い方法データの検証手順 を object に対して実行する。いかなる例外も再スローする。

            注記

            これらの手順により、IDL 型への変換および検証時のエラーができるだけ早い段階で検出されます。

      7. 組を (paymentMethod.supportedMethods、 serializedData) として serializedMethodData に追加する。
5. 合計の処理:
   1. 合計金額の確認および正規化 を details.total.amount に対して行う。 発生した例外は再スローする。
6. details の displayItems メンバーが存在する場合は、 details.displayItems 内の各 item について:
   1. 金額の確認および正規化 を item.amount に対して行う。例外は再スローする。
7. selectedShippingOption を null とする。
8. options の requestShipping メンバーが存在し、true に設定されている場合、配送オプションを処理する:
   1. options を空の sequence<PaymentShippingOption> とする。
   2. details の shippingOptions メンバーが存在する場合は、次を行う:
      1. seenIDs を空の集合とする。
      2. details.shippingOptions 内の 各 option について:
         1. 金額の確認および正規化 を item.amount に対して行う。例外は再スローする。
         2. もし seenIDs が option.id を含むなら、 TypeError を投げる。 任意で、配送オプションの ID は一意でなければならないことを開発者に通知する。
         3. そうでなければ、 option.id を seenIDs に追加する。
         4. もし option.selected が true の場合、selectedShippingOption を option.id に設定する。
   3. details.shippingOptions を options に設定する。
9. serializedModifierData を空のリストとする。
10. 支払い詳細のモディファイアを処理する:
    1. modifiers を空の sequence<PaymentDetailsModifier> とする。
    2. details の modifiers メンバーが 存在する場合は:
       1. modifiers を details.modifiers に設定する。
       2. modifiers の各 modifier について:
          1. もし modifier の total メンバーが存在する場合:
             1. 合計金額の確認および正規化 を modifier.total.amount に対して行う。 例外は再スローする。
          2. もし additionalDisplayItems メンバーが modifier に存在する場合、modifier.additionalDisplayItems の各 item について:
             1. 金額の確認および正規化 を item.amount に対して行う。 例外は再スローする。
          3. もし modifier の data メンバーが存在しない場合、serializedData を null とする。そうでなければ、 直列化 により modifier.data を JSON 文字列にし、 その結果を serializedData とする。例外は再スローする。
          4. 組を (modifier.supportedMethods、 serializedData) として serializedModifierData に追加する。
          5. 存在する場合は、modifier の data メンバーを削除する。
    3. details.modifiers を modifiers に設定する。
11. request を新しい PaymentRequest として作成する。
12. request の [[handler]] を null に設定する。
13. request の [[options]] を options に設定する。
14. request の [[state]] を "created" に設定する。
15. request の [[updating]] を false に設定する。
16. request の [[details]] を details に設定する。
17. request の [[serializedModifierData]] を serializedModifierData に設定する。
18. request の [[serializedMethodData]] を serializedMethodData に設定する。
19. request の [[response]] を null に設定する。
20. request の shippingOption 属性の値を、selectedShippingOption に設定する。
21. request の shippingAddress 属性の値を null に設定する。
22. もし options.requestShipping が true に設定されているなら、 request の shippingType 属性の値を、options.shippingType に設定する。そうでなければ、 null に設定する。
23. request を返す。

取得時、id 属性はこの PaymentRequest の [[details]].id を返します。

show(optional detailsPromise) メソッドは以下のように動作しなければなりません（MUST）:

1. request を this とする。
2. request の 関連グローバルオブジェクトが 一時的アクティベーションを持たない場合、ユーザーエージェントは次を行ってもよい（MAY）:
   1. 「SecurityError」の DOMException を用いて 拒否された Promise を返す。
   注記

   これは、ユーザーアクティベーションが不要となることをユーザーエージェントに許可します。例えば、リダイレクト先でユーザーアクティベーションが存在しない可能性のあるリダイレクトフローをサポートするためです。セキュリティ上の考慮事項については、 19.9 ユーザーアクティベーションの要件を参照してください。

   また、 issue #1022 も参照してください。ここでは、show() にユーザーアクティベーションを必要とすべきか否かについて、仕様でさらなる指針を提供することに関する議論が行われています。

3. それ以外の場合は、ユーザーアクティベーションを消費する（関連グローバルオブジェクトのアクティベーション）。
4. document を、request の 関連グローバルオブジェクトに 関連付けられた Document とする。
5. document が 完全にアクティブでない場合、 「AbortError」の DOMException で 拒否された Promise を返す。
6. document の 可視状態 が "visible" でない場合、 「AbortError」の DOMException で 拒否された Promise を返す。

7. 任意で、ユーザーエージェントがユーザー保護のために show() の呼び出しを不許可にしたい場合、 「SecurityError」の DOMException で拒否された Promise を返す。例えば、ユーザーエージェントは、 セクション 19. プライバシーとセキュリティに関する考慮事項 に記載のとおり、ページが show() を呼び出せる頻度を制限する場合がある。

8. request の [[state]] が "created" でない場合、 「InvalidStateError」の DOMException で 拒否された Promise を返す。
9. ユーザーエージェントの payment request is showing 真偽値が true の場合:
   1. request の [[state]] を "closed" に設定する。
   2. 「AbortError」の DOMException で 拒否された Promise を返す。
10. request の [[state]] を "interactive" に設定する。
11. acceptPromise を 新しい Promise とする。
12. request の [[acceptPromise]] を acceptPromise に設定する。

13. 任意で:

    1. acceptPromise を 「AbortError」の DOMException で拒否する。
    2. request の [[state]] を "closed" に設定する。
    3. acceptPromise を返す。
    注記

    これにより、ユーザーエージェントは、裁量により、ユーザーが即座に 支払いリクエストを中止したかのように振る舞うことができます。例えば「プライベートブラウジング」モードなどでは、この手順が利用されることがあります。

14. request の 支払い関連の閲覧コンテキストの payment request is showing 真偽値を true に設定する。
15. acceptPromise を返し、残りの手順は並行して実行する。
16. handlers を空の リストとする。
17. request の [[serializedMethodData]] 内の各 paymentMethod の組について:
    1. paymentMethod の最初の要素を identifier とする。
    2. 2番目の要素を JSON 解析 した結果を data とする。
    3. identifier を定義する仕様が 追加データ型 を規定している場合は、 変換 により data をその型の IDL 値にする。そうでなければ、 変換 により data を object にする。
    4. 変換により 例外 error が発生した場合:
       1. request の [[state]] を "closed" に設定する。
       2. acceptPromise を error で拒否する。
       3. request の 支払い関連の閲覧コンテキストの payment request is showing 真偽値を false に設定する。
       4. このアルゴリズムを終了する。
    5. registeredHandlers を、支払い方法 identifier の登録済み支払いハンドラーの リスト とする。
       注記: Payment Handler registration
    6. registeredHandlers 内の各 handler について:
       1. handler の 支払いが可能かどうかを確認する手順 を data とともに実行した結果を canMakePayment とする。
       2. canMakePayment が true の場合、handler を handlers に追加する。
18. handlers が空である場合:
    1. request の [[state]] を "closed" に設定する。
    2. acceptPromise を 「NotSupportedError」の DOMException で拒否する。
    3. request の 支払い関連の閲覧コンテキストの payment request is showing 真偽値を false に設定する。
    4. このアルゴリズムを終了する。

19. ユーザーが handlers と対話できるユーザーインターフェイスを提示する。提示にあたって、ユーザーエージェントはユーザーの選好を優先すべきです（SHOULD）。 また、ユーザーインターフェイスは、可能であれば document の 文書要素の 言語およびロケールに基づく書式に従って提示すべきです（SHOULD）。 利用できない場合は適切なフォールバックを用います。

    注記: 支払いユーザーインターフェイスのローカライズ
20. detailsPromise が渡された場合:
    1. detailsPromise、request、null を引数として、 PaymentRequest の詳細を更新するアルゴリズムを実行する。
    2. detailsPromise が settle するまで待つ。
       注記

       detailsPromise の settle 方法に基づいて、 PaymentRequest の詳細を更新するアルゴリズム が支払いUIの挙動を決定します。 すなわち、detailsPromise が 拒否された場合、支払いリクエストは中止されます。 それ以外の場合、detailsPromise が 履行 されると、 ユーザーエージェントは支払いUIを再度有効化し、支払いフローを継続できます。

21. request の [[handler]] を、エンドユーザーが選択した 支払いハンドラー に設定する。
22. modifiers を空のリストとする。
23. [[serializedModifierData]] 内の各 tuple について:
    1. tuple の最初の要素（PMI）が、 request の [[handler]] の 支払い方法識別子 と一致する場合、 2番目の要素（直列化されたメソッドデータ）を modifiers に追加する。

24. paymentMethod の組の2番目の要素を 変換 したものと modifiers を渡す。任意で、ユーザーエージェントは、ユーザーが支払いプロセスを進められるよう、 request から適切なデータをユーザー選択の 支払いハンドラー に送るべきです（SHOULD）。これには、 request のさまざまな属性やその他の 内部スロット が含まれます（プライバシー上の理由から、適宜一部が除外されることがあります）。

    [[serializedModifierData]] の 内部スロット にある 複数の適用可能なモディファイアの扱いは、支払いハンドラー に依存し、この仕様の範囲外です。 それでもなお、支払いハンドラー は「最後のものが優先」するアプローチを用いることが推奨されます（RECOMMENDED）。 つまり、リストの末尾の項目は常に先頭の項目より優先されます（以下の例を参照）。

    acceptPromise は、後に ユーザーが支払いリクエストを受諾するアルゴリズム または ユーザーが支払いリクエストを中止するアルゴリズム のいずれかによって、解決または拒否されます。これらはユーザーインターフェイスとの対話を通じてトリガーされます。

    ユーザーインターフェイスが表示されている間に document が 完全にアクティブでなくなった場合、またはこの手順に到達する時点で既にそうでない場合は、次を行う:

    1. ユーザーインターフェイスを閉じる。
    2. request の 支払い関連の閲覧コンテキストの payment request is showing 真偽値を false に設定する。

abort() メソッドは以下のように動作しなければなりません（MUST）:

1. request を this とする。
2. request.[[response]] が null でなく、 request.[[response]].[[retryPromise]] が null でない場合、「InvalidStateError」の DOMException で 拒否された Promise を返す。
3. request.[[state]] の値が "interactive" でない場合、「InvalidStateError」の DOMException で 拒否された Promise を返す。
4. promise を 新しい Promise とする。
5. promise を返し、残りの手順は並行して実行する。
6. 支払いハンドラーを用いて現在のユーザー対話を中止し、 残っているユーザーインターフェイスを閉じるよう試みる。
7. タスクをキューに追加し、 ユーザーインタラクションタスクソース上で 次の手順を実行する:
   1. 現在のユーザー対話を中止することができない場合、promise を 「InvalidStateError」の DOMException で拒否し、 これらの手順を中止する。
   2. request.[[state]] を "closed" に設定する。
   3. request.[[acceptPromise]] を 「AbortError」の DOMException で拒否する。
   4. promise を undefined で解決する。

canMakePayment() メソッドはcan make payment アルゴリズムを実行しなければなりません（MUST）。

PaymentRequest の shippingAddress 属性は、 ユーザーが配送先住所を提供したときに設定されます。デフォルトでは null です。 ユーザーが配送先住所を提供すると、配送先住所変更アルゴリズムが実行されます。

PaymentRequest の shippingType 属性は、 取引を履行するために使用される配送の種類を表します。その値は PaymentShippingType 列挙型の値か、 開発者が PaymentOptions の shippingType メンバーを使用して 構築する際に提供されていない場合は null です。

PaymentRequest の onshippingaddresschange 属性は、EventHandler であり、 PaymentRequestUpdateEvent のうち shippingaddresschange と名付けられたもの用です。

PaymentRequest の shippingOption 属性は、 ユーザーが配送オプションを選択したときに設定されます。デフォルトでは null です。 ユーザーが配送オプションを選択すると、配送オプション変更アルゴリズムが実行されます。

PaymentRequest の onshippingoptionchange 属性は、EventHandler であり、 PaymentRequestUpdateEvent のうち shippingoptionchange と名付けられたもの用です。

PaymentRequest の onpaymentmethodchange 属性は、EventHandler であり、 PaymentMethodChangeEvent のうち "paymentmethodchange" と名付けられたもの用です。

PaymentRequest のインスタンスは、 以下の表に示す内部スロットとともに作成されます:

内部スロット	説明 (規範ではない)
[[serializedMethodData]]	コンストラクタに提供された methodData ですが、元のオブジェクト形式の代わりに、サポートされる方法とデータの文字列または null を含むタプルとして表されます。
[[serializedModifierData]]	シーケンス [[details]] の modifier 内の各項目に対応する data メンバーの文字列形式で直列化されたリスト、またはそのようなメンバーが存在しなかった場合は null。
[[details]]	コンストラクタに最初に提供され、その後 updateWith() の呼び出しによって更新される、支払いリクエスト用の現在の PaymentDetailsBase。 data メンバーはすべて削除され、 代わりに直列化された形式で [[serializedModifierData]] 内部スロットに格納されます。
[[options]]	コンストラクタに提供された PaymentOptions。
[[state]]	支払いリクエストの現在の 状態。 以下のように遷移します: "created" 支払いリクエストが作成され、ユーザーに提示されていない。 "interactive" 支払いリクエストがユーザーに提示されている。 "closed" 支払いリクエストが完了した。 状態遷移は以下の図に示されています:
[[updating]]	保留中の updateWith() 呼び出しが支払いリクエストを更新するために存在する場合は true、それ以外の場合は false。
[[acceptPromise]]	show() 中に作成される保留中の Promise。 ユーザーが支払いリクエストを受け入れた場合に解決されます。
[[response]]	Null、またはこの PaymentRequest によって インスタンス化された PaymentResponse。
[[handler]]	この PaymentRequest に関連付けられた 支払いハンドラー。 初期値は null。

JavaScript の文字列 は、以下の順序で構成される場合に 有効な10進数形式の金額 です:

1. オプションで、U+002D (-) を一つだけ含む。これは金額が負であることを示します。
2. U+0030 (0) から U+0039 (9) の範囲内の コードポイントを1つ以上含む。
3. オプションで、U+002E (.) を一つ含み、その後に U+0030 (0) から U+0039 (9) の範囲内の コードポイントを1つ以上含む。

^-?[0-9]+(\.[0-9]+)?$

PaymentCurrencyAmount amount を与えて 金額の確認および正規化を行うには、次の手順を実行します:

1. IsWellFormedCurrencyCode(amount.currency) の結果が false である場合、RangeError 例外をスローし、オプションで開発者に通貨が無効であることを通知します。
2. amount.value が 有効な10進数形式の金額でない場合、 TypeErrorをスローし、 オプションで開発者に通貨が無効であることを通知します。
3. amount.currency を ASCII 大文字に変換した結果に設定します。

PaymentCurrencyAmount amount を与えて 合計金額の確認および正規化を行うには、次の手順を実行します:

1. 金額の確認および正規化を amount に対して行います。 例外を再スローします。
2. amount.value の最初の コードポイント が U+002D (-) の場合、 TypeError をスローし、 オプションで開発者に合計の値が負の数にできないことを通知します。

WebIDLdictionary PaymentDetailsBase {
  sequence<PaymentItem> displayItems;
  sequence<PaymentShippingOption> shippingOptions;
  sequence<PaymentDetailsModifier> modifiers;
};

displayItems メンバー

PaymentItem辞書のシーケンス。 ユーザーエージェントが表示できる支払いリクエストの行項目を含みます。

注意

shippingOptions メンバー

ユーザーが選択できるさまざまな配送オプションを含むシーケンスです。

シーケンス内のアイテムに selected メンバーが設定されている場合、それがデフォルトで使用される配送オプションとなり、 shippingOption は設定されます。 idに設定されます。

shippingOptions メンバーは、 PaymentRequest が PaymentOptions と requestShipping を設定した場合にのみ使用されます。

注意

modifiers メンバー

特定の支払い方法識別子の修飾子を含む PaymentDetailsModifier辞書のシーケンス。 例えば、支払い方法に基づいて合計金額を調整することができます。

WebIDLdictionary PaymentDetailsInit : PaymentDetailsBase {
  DOMString id;
  required PaymentItem total;
};

PaymentDetailsBase 辞書から継承されたメンバーに加えて、以下のメンバーが PaymentDetailsInit 辞書の一部です:

id メンバー

この支払いリクエストの自由形式の識別子。

注意

total メンバー

支払いリクエストの非負の合計金額を含む PaymentItem。

注意

WebIDLdictionary PaymentDetailsUpdate : PaymentDetailsBase {
  DOMString error;
  PaymentItem total;
  AddressErrors shippingAddressErrors;
  PayerErrors payerErrors;
  object paymentMethodErrors;
};

PaymentDetailsUpdate 辞書は、updateWith() を使用して支払いリクエストを更新するために使用されます。

PaymentDetailsBase 辞書から継承されたメンバーに加えて、以下のメンバーが PaymentDetailsUpdate 辞書の一部です:

error メンバー

選択された配送先住所に商品を配送できない理由や、配送オプションが利用できないその他の理由を説明する、人間が読める文字列。 updateWith() を使用して支払いリクエストが更新される場合、 PaymentDetailsUpdate は、error メンバーにメッセージを含めることができ、 shippingOptions が有効でない場合、ユーザーに表示されます。

total メンバー

非負のPaymentItemを含みます。

注意

この仕様のアルゴリズムは、 PaymentDetailsUpdate 辞書を受け入れる際、 total.amount.value が負の数値である場合に例外をスローします。

shippingAddressErrors メンバー

潜在的なイベントターゲットに関連付けられた配送先住所の検証エラーを表します。

payerErrors メンバー

支払者の詳細に関連する検証エラー。

paymentMethodErrors メンバー

支払い方法に特有のエラー。

retry(errorFields) メソッドは、次のように動作しなければなりません（MUST）:

1. response を this とする。
2. request を response.[[request]] とする。
3. document を、request の relevant global object の 関連付けられた Document とする。
4. document が fully active でない場合は、"AbortError" の DOMException で 拒否された promise を返す。
5. response.[[complete]] が true の場合、"InvalidStateError" の DOMException で 拒否された promise を返す。
6. response.[[retryPromise]] が null でない場合、"InvalidStateError" の DOMException で 拒否された promise を返す。
7. request.[[state]] を "interactive" に設定する。
8. retryPromise を 新しい promise とする。
9. response.[[retryPromise]] を retryPromise に設定する。
10. errorFields が渡された場合:
    1. 任意で、次のいずれかが真である場合は開発者コンソールに警告を表示してもよい:
       1. request.[[options]].requestPayerName が false であり、かつ errorFields.payer.name が存在する場合。
       2. request.[[options]].requestPayerEmail が false であり、かつ errorFields.payer.email が存在する場合。
       3. request.[[options]].requestPayerPhone が false であり、かつ errorFields.payer.phone が存在する場合。
       4. request.[[options]].requestShipping が false であり、かつ errorFields.shippingAddress が存在する場合。
    2. errorFields.paymentMethod メンバーが渡され、かつ response.methodName を定義する仕様でそれが要求されている場合は、errorFields の paymentMethod メンバーをそこで指定された型の IDL 値に変換する。そうでない場合は、object に変換する。
    3. request の 支払い関連の閲覧コンテキスト の payment request is showing 真偽値を false に設定する。
    4. 変換が 例外 error を生じた場合:
       1. retryPromise を error で拒否する。
       2. ユーザーエージェント の payment request is showing 真偽値を false に設定する。
       3. 戻る。
    5. errorFields の各メンバーをユーザーエージェントの UI 内の対応する入力フィールドに対応付けることで、支払い応答データに問題があることをエンドユーザーに示す。例えば、ユーザーエージェントはブラウザーの UI で誤っている errorFields にユーザーの注意を向け、各フィールドの値を、ユーザーが各エラーを修正しやすいような方法で表示してもよい。同様に、error メンバーが渡された場合は、そのエラーをユーザーエージェントの UI に提示する。メンバーの値が空文字列である場合、ユーザーエージェントは適切なエラーメッセージで値を代用してもよい（MAY）。
11. それ以外の場合、errorFields が渡されなかったときは、エンドユーザーに支払いの再試行を促す。支払いリクエストの受諾を再試行できるようにする UI 要素を再度有効化する。
12. document がユーザーインターフェイスの表示中に fully active でなくなる、またはこの段階に到達するまでに fully active でなくなった場合は、次を行う:
    1. ユーザーインターフェイスを閉じる。
    2. request の 支払い関連の閲覧コンテキスト の payment request is showing 真偽値を false に設定する。
13. 最後に、retryPromise が決着したとき、response.[[retryPromise]] を null に設定する。
14. retryPromise を返す。
    注意

    retryPromise は後に、ユーザーが支払いリクエストを受諾するアルゴリズム によって解決されるか、ユーザーが支払いリクエストを中止するアルゴリズム または 更新を中止 によって拒否されます。

WebIDLdictionary PaymentValidationErrors {
  PayerErrors payer;
  AddressErrors shippingAddress;
  DOMString error;
  object paymentMethod;
};

WebIDLdictionary PayerErrors {
  DOMString email;
  DOMString name;
  DOMString phone;
};

const payer = {
  email: "The domain is invalid.",
  phone: "Unknown country code.",
  name: "Not in database.",
};
await response.retry({ payer });

取引を完了するためにユーザーが選択した 支払い方法識別子（支払い方法）です。

マーチャントが取引を処理または検証するために使用できる、支払い方法 によって生成された object または dictionary（どの 支払い方法 かに依存します）。

requestShipping メンバーが、 PaymentRequest コンストラクタに渡された PaymentOptions 内で true に設定されていた場合、 shippingAddress はユーザーが選択した 完全かつ最終的な 配送先住所となります。

requestShipping メンバーが、 PaymentRequest コンストラクタに渡された PaymentOptions 内で true に設定されていた場合、 shippingOption は選択された配送オプションの id 属性となります。

requestPayerName メンバーが、 PaymentRequest コンストラクタに渡された PaymentOptions 内で true に設定されていた場合、 payerName はユーザーが提供した氏名となります。

requestPayerEmail メンバーが、 PaymentRequest コンストラクタに渡された PaymentOptions 内で true に設定されていた場合、 payerEmail はユーザーが選択したメールアドレスとなります。

requestPayerPhone メンバーが、 PaymentRequest コンストラクタに渡された PaymentOptions 内で true に設定されていた場合、 payerPhone はユーザーが選択した電話番号となります。

この支払い応答を生成した対応する支払いリクエストの id。

支払いリクエストが受諾され、呼び出し元に PaymentResponse が返された後で、 呼び出し元が complete() を呼び出す前は、 支払いリクエストのユーザーインターフェイスは保留状態のままです。 この時点では支払いリクエストの受諾が返ってきているため、ユーザーインターフェイスはキャンセルコマンドを提供すべきではありません（SHOULD NOT）。 しかし、何らかの問題が発生し開発者が complete() を呼び出さない場合、 ユーザーインターフェイスはブロックされます。

このため、実装は開発者が complete() を呼び出すための タイムアウトを課してもよい（MAY）とします。タイムアウトが期限切れになった場合、 引数なしで complete() が呼び出されたかのように動作します。

complete() メソッドは次のように動作しなければなりません（MUST）:

1. response を this とする。
2. response.[[complete]] が true の場合、 "InvalidStateError" の DOMException で 拒否された promise を返す。
3. response.[[retryPromise]] が null でない場合、 "InvalidStateError" の DOMException で 拒否された promise を返す。
4. promise を 新しい promise とする。
5. serializedData を、 serialize により details.data を JSON 文字列へ直列化した結果とする。
6. 直列化が 例外を送出 した場合、 その例外で 拒否された promise を返す。
7. response.methodName を定義する仕様で要求されている場合:
   1. json を、JSON の parse() に serializedData を渡して呼び出した結果とする。
   2. idl を、変換 により json を、当該仕様で指定された型の IDL 値へ変換した結果とする。
   3. IDL 値への変換が 例外を送出 した場合、 その例外で 拒否された promise を返す。
   4. さらに、response.methodName を定義する仕様で要求されている場合、 idl のメンバーを検証する。メンバーの値が無効であれば、 拒否された promise を TypeError で返す。
      注意: 復旧の機会
8. response.[[complete]] を true に設定する。
9. promise を返し、残りの手順を 並行して実行する。
10. document が、ユーザーインターフェイスの表示中に fully active でなくなる、またはこの段階に達するまでに fully active でなくなった場合は、次を行う:
    1. ユーザーインターフェイスを閉じる。
    2. request の 支払い関連の閲覧コンテキスト の payment request is showing 真偽値を false に設定する。
11. それ以外の場合:
    1. 残っているユーザーインターフェイスを閉じる。 ユーザーエージェント は、 result と serializedData の値を用いて ユーザー体験に影響を与えてもよい（MAY）。
    2. request の 支払い関連の閲覧コンテキスト の payment request is showing 真偽値を false に設定する。
    3. promise を undefined で解決する。

開発者が "payerdetailchange" イベントを処理できるようにします。

PaymentResponse のインスタンスは、 次の表の internal slots とともに作成されます:

WebIDLdictionary AddressErrors {
  DOMString addressLine;
  DOMString city;
  DOMString country;
  DOMString dependentLocality;
  DOMString organization;
  DOMString phone;
  DOMString postalCode;
  DOMString recipient;
  DOMString region;
  DOMString sortingCode;
};

AddressErrors 辞書のメンバーは、 物理的住所の特定の部分に関する検証エラーを表します。 各辞書メンバーには二重の機能があります。第一に、そのメンバーが存在することは住所の特定部分に検証エラーがあることを示します。 第二に、その文字列値により、開発者は検証エラー（およびエンドユーザーがエラーをどのように修正できるか）を記述できます。

addressLine メンバー

住所行 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の addressLine 属性値を提供した入力フィールドに対応します。

city メンバー

市区町村 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の city 属性値を提供した入力フィールドに対応します。

country メンバー

国 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の country 属性値を提供した入力フィールドに対応します。

dependentLocality メンバー

小地域（dependent locality） に検証エラーがあることを示します。ユーザーエージェントの UI では、このメンバーは ContactAddress の dependentLocality 属性値を提供した入力フィールドに対応します。

organization メンバー

組織名 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の organization 属性値を提供した入力フィールドに対応します。

phone メンバー

電話番号 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の phone 属性値を提供した入力フィールドに対応します。

postalCode メンバー

郵便番号 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の postalCode 属性値を提供した入力フィールドに対応します。

recipient メンバー

受取人 に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の addressLine 属性値を提供した入力フィールドに対応します。

region メンバー

地域（都道府県など） に検証エラーがあることを示します。 ユーザーエージェントの UI では、このメンバーは ContactAddress の region 属性値を提供した入力フィールドに対応します。

sortingCode メンバー

ソーティングコード に検証エラーがあります。 ユーザーエージェントの UI では、このメンバーは ContactAddress の sortingCode 属性値を提供した入力フィールドに対応します。

WebIDL[SecureContext, Exposed=Window]
interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
  constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict = {});
  readonly attribute DOMString methodName;
  readonly attribute object? methodDetails;
};

WebIDLdictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
  DOMString methodName = "";
  object? methodDetails = null;
};

WebIDL[SecureContext, Exposed=Window]
interface PaymentRequestUpdateEvent : Event {
  constructor(DOMString type, optional PaymentRequestUpdateEventInit eventInitDict = {});
  undefined updateWith(Promise<PaymentDetailsUpdate> detailsPromise);
};

PaymentRequestUpdateEvent は、 ユーザー操作に応答して支払いリクエストの詳細を更新できるようにします。

WebIDLdictionary PaymentRequestUpdateEventInit : EventInit {};

支払い可能かどうかのアルゴリズムは、 ユーザーエージェントが 支払い方法により 支払いを実行できるかを、PaymentRequest が構築された際に指定されたそれらの 支払い方法に対して確認します。

1. メソッドが呼び出された対象の request を、PaymentRequest オブジェクトとする。
2. request.[[state]] が "created" でない場合、 "InvalidStateError" の DOMException で拒否された promise を返す。
3. 任意で、 トップレベル閲覧コンテキスト の裁量で、"NotAllowedError" の DOMException で拒否された promise を返してもよい。
   注意

   これは、フィンガープリント目的での呼び出しメソッドの乱用を検出・防止するために、 ユーザーエージェントがヒューリスティクスを適用できるようにするものです。例えば、 さまざまなサポート対象のPaymentRequest オブジェクトを作成し、 多様な支払い方法を指定して、 それらに対して順番に 支払い可能かどうかのアルゴリズム をトリガーする、といった場合です。 例えば、ユーザーエージェントは成功する呼び出し回数を、 トップレベル閲覧コンテキスト やそれらの呼び出しが行われた期間に基づいて制限するかもしれません。

4. hasHandlerPromise を 新しい promise とする。
5. hasHandlerPromise を返し、残りの手順を 並行して実行する。
6. request の [[serializedMethodData]] の各 paymentMethod タプルについて:
   1. identifier を、その paymentMethod タプルの最初の要素とする。
   2. ユーザーエージェントが identifier に対する支払い要求を処理可能な 支払いハンドラー を持つ場合、 hasHandlerPromise を true で解決し、このアルゴリズムを終了する。
7. hasHandlerPromise を false で解決する。

配送先住所変更アルゴリズムは、ユーザーが新しい配送先住所を提供したときに実行されます。 これは以下の手順を実行しなければなりません（MUST）。

1. ユーザーが操作している PaymentRequest オブジェクトを request とする。
2. タスクをキューに入れ、 ユーザー操作タスクソース上で 次の手順を実行する:
   1. 注意: 受取人情報のプライバシー

      redactList は、この API が商人と共有する受取人に関する個人情報の量を制限します。

      商人にとって、結果として得られる ContactAddress オブジェクトは、例えば配送料の計算に十分な情報を提供しますが、 多くの場合、受取人を物理的に特定し一意に識別するのに十分な情報は提供しません。

      残念ながら、redactList があっても受取人の匿名性は保証できません。 これは、一部の国では郵便番号が非常に細分化されており、 それ自体で受取人を一意に識別できてしまうためです。

   2. redactList を空のリストとする。redactList を « "organization", "phone", "recipient", "addressLine" » に設定する。
   3. address を、 redactList を用いて create a contactaddress from user-provided input の手順を実行した結果とする。
   4. request.shippingAddress を address に設定する。
   5. request と "shippingaddresschange" を引数に、 PaymentRequest 更新アルゴリズム を実行する。

配送オプション変更アルゴリズムは、ユーザーが新しい配送オプションを選択したときに実行されます。 これは以下の手順を実行しなければなりません（MUST）。

1. ユーザーが操作している PaymentRequest オブジェクトを request とする。
2. タスクをキューに入れ、 ユーザー操作タスクソース上で 次の手順を実行する:
   1. request 上の shippingOption 属性を、ユーザーが指定した PaymentShippingOption の id 文字列に設定する。
   2. request と "shippingoptionchange" を引数に、 PaymentRequest 更新アルゴリズム を実行する。

ユーザーが 支払い方法 を変更したとき、支払いハンドラーは、MAY（実施してもよい）として 支払い方法変更アルゴリズム を実行できます。 その際に渡される methodDetails は dictionary または object、あるいは null であり、 methodName は DOMString で、ユーザーが操作中の 支払いハンドラーの 支払い方法識別子 を表します。

1. ユーザーが操作している PaymentRequest オブジェクトを request とする。
2. Queue a task を user interaction task source 上に行い、 次の手順を実行する:
   1. Assert: request.[[updating]] は false であること。 同時に行える更新は 1 回のみである。
   2. Assert: request.[[state]] は "interactive" であること。
   3. Fire an event で、名前が "paymentmethodchange" のイベントを request に対して発火し、 PaymentMethodChangeEvent を用いる。 このとき、 methodName 属性は methodName に初期化し、 methodDetails 属性は methodDetails に初期化する。

PaymentRequest 更新アルゴリズム は、 上記の他のアルゴリズムから呼び出され、ユーザーが PaymentRequest （request）に対して変更を行ったことを示すための イベントの発火を行う。 発火するイベント名は name とする。

1. Assert: request.[[updating]] は false であること。 同時に行える更新は 1 回のみである。
2. Assert: request.[[state]] は "interactive" であること。
3. event を、 creating an event により PaymentRequestUpdateEvent インターフェイスを用いて作成した結果とする。
4. event の type 属性を name に初期化する。
5. Dispatch event を request に対して行う。
6. もし event.[[waitForUpdate]] が true なら、 追加の更新イベントを発火させる可能性のある UI の部分を無効化する。
7. それ以外の場合は、 event.[[waitForUpdate]] を true に設定する。

ユーザーが UI で payer name、payer email、または payer phone を変更したとき、ユーザーエージェントは MUST（実施しなければならない）として 支払者詳細変更アルゴリズム を実行する。

1. ユーザーが操作している PaymentRequest オブジェクトを request とする。
2. request.[[response]] が null の場合は、何もせず戻る。
3. response を request.[[response]] とする。
4. Queue a task を user interaction task source 上に行い、 次の手順を実行する:
   1. Assert: request.[[updating]] は false であること。
   2. Assert: request.[[state]] は "interactive" であること。
   3. options を request.[[options]] とする。
   4. payer name が変更され、かつ options.requestPayerName が true の場合:
      1. response.payerName 属性を payer name に設定する。
   5. payer email が変更され、かつ options.requestPayerEmail が true の場合:
      1. response.payerEmail を payer email に設定する。
   6. payer phone が変更され、かつ options.requestPayerPhone が true の場合:
      1. response.payerPhone を payer phone に設定する。
   7. event を、 creating an event により PaymentRequestUpdateEvent を用いて作成した結果とする。
   8. event の type 属性を "payerdetailchange" に初期化する。
   9. Dispatch event を response に対して行う。
   10. もし event.[[waitForUpdate]] が true なら、 支払者詳細のさらなる変更を発火させる可能性のある UI の部分を無効化する。
   11. それ以外の場合は、 event.[[waitForUpdate]] を true に設定する。

ユーザーが支払いリクエストを受諾するアルゴリズム は、 ユーザーが支払いリクエストを受諾し、支払う意思を確認したときに実行されます。次の手順を実行するため、 タスクをキューに入れ、 user interaction task source 上で実行しなければなりません（MUST）。

1. request を、ユーザーが操作している PaymentRequest オブジェクトとする。
2. もし request.[[updating]] が true なら、 このアルゴリズムを終了し、それ以上の処理を行わない。ユーザーエージェントの ユーザーインターフェイスは、この状況が決して起こらないようにすべきです（SHOULD）。
3. request.[[state]] が "interactive" でない場合、 このアルゴリズムを終了し、それ以上の処理を行わない。ユーザーエージェントのユーザーインターフェイスは、 この状況が決して起こらないようにすべきです（SHOULD）。
4. requestShipping の値が request.[[options]] において true の場合で、 request の shippingAddress 属性が null、 または request の shippingOption 属性が null の場合、このアルゴリズムを終了し、それ以上の処理を行わない。 ユーザーエージェント は、この状況が決して起こらないようにすべきです（SHOULD）。
5. isRetry を、 request.[[response]] が null でないなら true、 そうでなければ false とする。
6. response を、 isRetry が true の場合は request.[[response]] とし、そうでない場合は 新しい PaymentResponse とする。
7. isRetry が false の場合、新たに作成した response を初期化する:
   1. response.[[request]] を request に設定する。
   2. response.[[retryPromise]] を null に設定する。
   3. response.[[complete]] を false に設定する。
   4. response の requestId 属性値を、 request.[[details]] の id の値に設定する。
   5. request.[[response]] を response に設定する。
8. handler を、 request.[[handler]] とする。
9. response の methodName 属性値を、 handler の 支払い方法識別子 に設定する。
10. response の details 属性値を、 handler の steps to respond to a payment request を実行して得られるオブジェクトに設定する。
11. requestShipping の値が request.[[options]] において false の場合、 response の shippingAddress 属性値を null に設定する。そうでなければ:
    1. shippingAddress を、 create a contactaddress from user-provided input の結果とする。
    2. response の shippingAddress 属性値を shippingAddress に設定する。
    3. request の shippingAddress 属性値を shippingAddress に設定する。
12. requestShipping の値が request.[[options]] において true の場合、 response の shippingOption 属性を、 request の shippingOption 属性の値に設定する。 そうでなければ null に設定する。
13. requestPayerName の値が request.[[options]] において true の場合、 response の payerName 属性を、ユーザーが提供した 支払者の氏名に（提供がなければ null に）設定する。そうでなければ null に設定する。
14. requestPayerEmail の値が request.[[options]] において true の場合、 response の payerEmail 属性を、ユーザーが提供した 支払者のメールアドレスに（提供がなければ null に）設定する。そうでなければ null に設定する。
15. requestPayerPhone の値が request.[[options]] において true の場合、 response の payerPhone 属性を、ユーザーが提供した 支払者の電話番号に（提供がなければ null に）設定する。 payerPhone の値を設定する際、 ユーザーエージェントは [E.164] に準拠するよう 電話番号をフォーマットすべきです（SHOULD）。
16. request.[[state]] を "closed" に設定する。
17. isRetry が true の場合、 response.[[retryPromise]] を undefined で解決する。 そうでなければ、 request.[[acceptPromise]] を response で解決する。

ユーザーが支払いリクエストを中止するアルゴリズム は、 現在インタラクティブなユーザーインターフェイスを通じてユーザーが支払いリクエストを中止したときに実行されます。 次の手順を実行するために、 タスクをキューに入れ、 user interaction task source 上で実行しなければなりません（MUST）。

1. request を、ユーザーが操作している PaymentRequest オブジェクトとする。
2. request.[[state]] が "interactive" でない場合、 このアルゴリズムを終了し、それ以上の処理を行わない。ユーザーエージェントのユーザーインターフェイスは、 この状況が決して起こらないようにすべきです（SHOULD）。
3. request.[[state]] を "closed" に設定する。
4. request の payment-relevant browsing context の payment request is showing 真偽値を false に設定する。
5. error を、"AbortError" の DOMException とする。
6. response を、 request.[[response]] とする。
7. response が null でない場合:
   1. response.[[complete]] を true に設定する。
   2. Assert: response.[[retryPromise]] は null ではない。
   3. response.[[retryPromise]] を error で拒否する。
8. それ以外の場合は、 request.[[acceptPromise]] を error で拒否する。
9. 現在のユーザーインタラクションを中止し、残っているユーザーインターフェイスをすべて閉じる。

PaymentRequest の details を更新する アルゴリズムは、PaymentDetailsUpdate の detailsPromise、PaymentRequest の request、および DOMString か null（支払い方法識別子）である pmi を受け取ります。手順は detailsPromise の決着に依存します。もし detailsPromise が決着しない場合、 支払いリクエストはブロックされます。ユーザーエージェントは支払いリクエストを中止する手段を提供すべきです（SHOULD）。実装は、 detailsPromise が妥当な時間内に決着しない場合、保留中の更新にタイムアウトを設けてもよいです（MAY）。

タイムアウトが発生した場合、またはユーザーが手動で中止した場合、あるいは 支払いハンドラーが当該支払いを中止することを決定した場合には、 ユーザーエージェントは ユーザーが支払いリクエストを中止する アルゴリズムを実行しなければなりません（MUST）。

1. request.[[updating]] を true に設定する。
2. 並行して、 ユーザーが支払いリクエストを受諾できるユーザーインターフェイスを無効にする。これは、ユーザーインターフェイスが新しい details で更新されるまで支払いが受諾されないようにするためです。
3. 拒否時（detailsPromise の拒否時）:
   1. 更新を中止し、request と "AbortError" の DOMException を用いる。
4. 履行時 （detailsPromise が値 value で解決されたとき）:
   1. details を、 IDL 値への変換により value を PaymentDetailsUpdate 辞書へ変換した結果とする。これが例外を 送出した場合は、 更新を中止し、request と その送出された例外を用いる。
   2. serializedModifierData を空のリストとする。
   3. selectedShippingOption を null とする。
   4. shippingOptions を空の sequence<PaymentShippingOption> とする。
   5. details を検証し正規化する:
      1. details の total メンバーが存在する場合:
         1. 合計額の確認と正規化 を details.total.amount に対して行う。 例外が送出された場合は、更新を中止 し、request とその例外を用いる。
      2. details の displayItems メンバーが存在する場合、各 item について details.displayItems 内を反復する:
         1. 金額の確認と正規化 を item.amount に対して行う。例外が 送出された場合は、更新を中止し、 request とその例外を用いる。
      3. details の shippingOptions メンバーが存在し、かつ request.[[options]].requestShipping が true の場合:
         1. seenIDs を空集合とする。
         2. 各 option について details.shippingOptions を反復する:
            1. 金額の確認と正規化 を option.amount に対して行う。 例外が 送出された場合は、更新を中止し、 request とその例外を用いる。
            2. もし seenIDs[option.{{PaymentShippingOption/id}] が 存在するなら、更新を中止し、 request と TypeError を用いる。
            3. option.id を seenIDs に追加する。
            4. option を shippingOptions に追加する。
            5. もし option.selected が true なら、 selectedShippingOption を option.id に設定する。
      4. details の modifiers メンバーが存在する場合:
         1. modifiers を次のシーケンスとする: details.modifiers。
         2. serializedModifierData を空のリストとする。
         3. 各 PaymentDetailsModifier の modifier について modifiers を反復する:
            1. 支払い方法識別子の検証 の手順を modifier.supportedMethods で実行する。false を返した場合は、 更新を中止し、 request と RangeError 例外を用いる。任意で、開発者に支払い方法識別子が無効であることを通知してもよい。
            2. modifier の total メンバーが存在する場合:
               1. 合計額の確認と正規化 を modifier.total.amount に対して行う。例外が送出された場合は 更新を中止し、 request とその例外を用いる。
            3. additionalDisplayItems が modifier に存在する場合、各 PaymentItem の item について modifier.additionalDisplayItems を反復する:
               1. 金額の確認と正規化 を item.amount に対して行う。 例外が送出された場合は 更新を中止し、 request とその例外を用いる。
            4. modifier の data メンバーが欠落している場合は、serializedData を null とする。 それ以外の場合、serializedData を 直列化により modifier.data を JSON 文字列へ変換した結果とする。例外が送出された場合は、 更新を中止し、 request とその例外を用いる。
            5. serializedData を serializedModifierData に追加する。
            6. 存在する場合は、modifier の data メンバーを削除する。
   6. paymentMethodErrors メンバーが存在し、かつ identifier が null でない場合:
      1. pmi を定義する仕様で要求される場合は、 変換を行い、 paymentMethodErrors を IDL 値へ変換する。
      2. 変換が 例外 error を生じた場合は、 更新を中止し、error を用いる。
      3. 支払いハンドラーは、 paymentMethodErrors の関連する誤った各フィールドに対してエラーを表示すべきです（SHOULD）。
   7. 新しい details を用いて PaymentRequest を更新する:
      1. details の total メンバーが存在する場合:
         1. request.[[details]].total を details.total に設定する。
      2. details の displayItems メンバーが存在する場合:
         1. request.[[details]].displayItems を details.displayItems に設定する。
      3. details の shippingOptions メンバーが存在し、かつ request.[[options]].requestShipping が true の場合:
         1. request.[[details]].shippingOptions を shippingOptions に設定する。
         2. request の shippingOption 属性の値を selectedShippingOption に設定する。
      4. details の modifiers メンバーが存在する場合:
         1. request.[[details]].modifiers を details.modifiers に設定する。
         2. request.[[serializedModifierData]] を serializedModifierData に設定する。

      5. もし request.[[options]].requestShipping が true で、 request.[[details]].shippingOptions が空である場合、開発者は現在選択されている配送先住所（request の shippingAddress により与えられる）に対して有効な配送オプションがないことを示しています。

         この場合、ユーザーエージェントはこの旨のエラーを表示すべきであり（SHOULD）、 現在選択されている配送先住所が何らかの理由で無効であることを示してもよいです（MAY）。 ユーザーエージェントは、存在する場合には error メンバーを用いて、その住所に有効な配送オプションがない理由に関する情報を提供すべきです（SHOULD）。

         さらに、 details["shippingAddressErrors"] メンバーが存在する場合、ユーザーエージェントは配送先住所の各誤ったフィールドに対して個別のエラーを表示すべきです（SHOULD）。 これは、表示されているユーザーインターフェイス内の対応する入力フィールドに、 AddressErrors の各存在するメンバーを対応付けることで行います。

         同様に、details["payerErrors"] メンバーが存在し、 かつ request.[[options]] の requestPayerName、 requestPayerEmail、 または requestPayerPhone が true の場合、各誤ったフィールドに対して個別のエラーを表示します。

         さらに、 details.paymentMethodErrors が存在する場合、当該支払い方法の各誤った入力フィールドに対して個別のエラーを表示します。

5. request.[[updating]] を false に設定する。
6. 変更された request 内の値に基づいてユーザーインターフェイスを更新する。 本アルゴリズムの実行前に無効化したユーザーインターフェイス要素を再び有効化する。

支払い方法の所有者は、その支払い方法のために収集されたユーザーデータがどのように利用され得るかについてのプライバシーポリシーを定めます。 Payment Request API は、データが取引完了の目的で利用されるという明確な期待を設定し、この API に関連するユーザー体験もその意図を伝えます。 受取人は、いかなるデータ利用も支払い方法のポリシーに適合していることを保証する責任を負います。 取引完了を超える許容された利用については、受取人はその利用をユーザーに明確に伝えるべきです。

ユーザーエージェントは、ユーザーの同意なしに、（例: 配送先住所）などのユーザーに関する情報を開発者と共有してはなりません（MUST NOT）。

特に、PaymentMethodData の data と、 PaymentResponse の details メンバーは、任意のデータ交換を可能にします。 既存の支払い方法で用いられるデータモデルは広範に及ぶため、この API でデータの詳細を規定すると有用性が制限されてしまいます。 details メンバーは、Web ベース（Payment Handler API により定義）であれプロプライエタリであれ、支払いハンドラーからのデータを運びます。 ユーザーエージェントは、十分なユーザー同意メカニズム（取引当事者の認識や、データ共有の意図を示す仕組みなど）を含まない限り、支払いハンドラーをサポートしてはなりません（MUST NOT）。

displayItems メンバーや additionalDisplayItems メンバーの値を、取引完了を容易にする目的以外で共有することは、ユーザーエージェントはしてはなりません（MUST NOT）。

PaymentMethodChangeEvent は、選択された 支払い方法に特有の情報に基づいて、表示される合計を受取人が更新できるようにします。 例えば、選択された支払い方法に関連付けられた請求先住所が税計算（例: VAT）に影響する可能性があるため、支払者が取引を完了する前に UI に正確な合計を表示できることが望まれます。 同時に、支払い完了前に共有される情報は可能な限り少ないことが望まれます。 したがって、ある支払い方法が ユーザーが支払い方法を変更したときの手順を定義する場合、 PaymentMethodChangeEvent の methodDetails 属性を通じて共有されるデータを最小化することが重要です。 共有データを最小化するための要件やアプローチは支払い方法によって異なる可能性があり、次のようなものが含まれ得ます:

• 物理的住所に対する "redactList" の利用。現行の仕様では、redactList を用いて 住所行、 組織、 電話番号、 および 受取人 をshippingAddress から秘匿します。
• 受取人からの指示により、支払い方法の応答データ （PaymentResponse.details を通じて返される）から、 特定の要素を除外・含めるためのサポート。 受取人はこれらの指示を PaymentMethodData.data を通じて提供でき、 現行 API を変更することなく支払い方法の定義が発展できるようにします。

プライバシーに敏感な情報の共有がユーザーにとって自明でない場合（例: 支払い方法の変更時など）、ユーザーエージェントは、どの情報が商人と共有されるかをユーザーに正確に通知することが推奨されます（RECOMMENDED）。

canMakePayment() メソッドは、さまざまな支払い方法に対するフィーチャー検出を提供します。 将来的に多数の支払い方法が利用可能になった場合、これはフィンガープリントの手段となり得ます。 ユーザーエージェントには、このメソッドの乱用からユーザーを保護することが期待されます。 例えば、ユーザーエージェントは次のようにしてユーザーフィンガープリンティングを低減できます:

• 異なるパラメータでの呼び出し頻度をレート制限する。

レート制限のため、ユーザーエージェントは以下からの繰り返し呼び出しを考慮できます:

• 同一の 登録可能ドメイン（registrable domain）。
• トップレベル閲覧コンテキスト。 あるいは、既知の悪質な オリジンに対しては、API へのアクセスを完全にブロックすることもできます。
• iframe またはポップアップウィンドウの オリジン。

これらのレート制限手法は、繰り返し呼び出しに伴うコストを増大させることを意図しています。 それは、複数の 登録可能ドメイン を管理するコストであったり、 複数のウィンドウ（タブやポップアップ）を開くことによるユーザー体験上の摩擦であったりします。

もしユーザーエージェントが、 show() メソッドの一部としてユーザーアクティベーションを要求しない場合、 追加のセキュリティ緩和策を検討する必要があります。 ユーザーアクティベーションを要求しないと、ページ上で直前のユーザー操作なしに Payment Request の UI を起動できてしまうため、 スパムやクリックジャッキング攻撃のリスクが高まります。

スパムを軽減するために、ユーザーエージェントはある閾値以降でユーザーアクティベーション要件を強制することを決定してもよいでしょう。 例えば、現在のページでユーザーアクティベーションなしに Payment Request の UI を既に表示した後などです。 クリックジャッキング攻撃を軽減するために、ユーザーエージェントはダイアログ表示直後の一定時間におけるクリックを無視する時間的閾値を実装してもよいでしょう。

もう 1 つの関連する緩和策は、 show() の手順 6 に存在し、 ユーザーインタラクションを開始するために文書が可視でなければならない点です。