A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/payment/REC-payment-method-id-20220908.html below:

決済方式è˜åˆ¥å

【注意】 このドキュメントは、W3CのPayment Method Identifiers W3C Recommendation 08 September 2022の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2023年2月19日

要約

この仕様は、決済方式の識別子と、その妥当性の検証方法、および該当する場合は、作成方法、W3Cでの正式な登録方法について定義しています。他の仕様(決済リクエストAPIなど)は、この識別子を利用して、ウェブのプラットフォーム上での金銭取引を促進します。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

ワーキンググループは、実装報告書を作成することにより、実装経験を実証します。この報告書は、テストスイートの各必須テスト(すなわち、各テストは仕様の要件に対応していなければならない(MUST))に合格した2つ以上の独立した実装を示します。

この仕様の開発中には、他のワーキンググループとの依存関係に変更はありませんでした。

このドキュメントは、ウェブ決済ワーキンググループ(Web Payments Working Group)が勧告トラックを用いて勧告として公開しました。

W3Cは、この仕様をウェブの標準として広く展開することを推奨します。

W3C勧告は、広範な合意形成の後、W3Cとそのメンバーの協賛を得て、ワーキンググループのメンバーから実装のためのロイヤルティ・フリーのライセンスを約束された仕様です。この勧告の将来の更新では、新しい機能を組み込む可能性があります。

このドキュメントは、2017年8月1日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2021年11月2日のW3Cプロセス・ドキュメントによって管理されています。

目次
  1. 要約
  2. このドキュメントのステータス
  3. 1. 決済方式識別子(PMI)
    1. 1.1 妥当性
  4. 2. URLベースの決済方式識別子
    1. 2.1 妥当性検証
    2. 2.2 比較
    3. 2.3 フェッチ(逆参照)
  5. 3. 標準的な決済方式識別子
    1. 3.1 妥当性
    2. 3.2 比較
  6. 4. 標準的な決済方式の登録
  7. 5. URLベースのPMIとサードパーティの決済ハンドラ
  8. 6. セキュリティに関する留意点
  9. 7. プライバシーに関する留意点
  10. 8. 適合性
  11. A. 索引
    1. A.1 この仕様で定義している用語
    2. A.2 参考文献で定義されている用語
  12. B. 参考文献
    1. B.1 規範的な参考文献
    2. B.2 参考情報の参考文献

決済方式識別子(payment method identifier: PMI)は、次のいずれかです。

決済方式識別子に依存する仕様は、無効な決済方式識別子を処理するための独自のルールを指定しなければならなりません(MUST)。

文字列pmiで決済方式識別子の妥当性検証を行う手順を次のアルゴリズムで示します。これは、pmiが有効である場合に真(true)を返します。

  1. urlを、pmiで基本的なURLパーサを実行した結果とします。
  2. urlに失敗した場合、pmiで標準的な決済方式識別子の妥当性検証を行い、結果を返します。
  3. そうでない場合、urlを渡すURLベースの決済方式識別子の妥当性検証を行い、その結果を返します。

URLベースの決済方式識別子は、URLベースの決済方式識別子の妥当性検証を行うための手順にしたがった有効なURLです。

注

サードパーティの決済ハンドラにURLベースの決済方式識別子を用いたい開発者は、決済方式ベスト・プラクティス・ドキュメントを読むことをお勧めします。

URLベースの決済方式識別子の妥当性検証を行う手順を次のアルゴリズムで示します。このアルゴリズムは、URLであるurlを入力とし、URLが有効である場合に真(true)を返します。

  1. urlのスキームが「https」でない場合、偽(false)を返します。
  2. urlのユーザー名またはパスワードが空の文字列でない場合、偽(false)を返します。
  3. そうでない場合、真(true)を返します。
例 1: 有効および無効なURLベースのPMI 
const valid = [
  {
    supportedMethods: "https://example.com/pay",
  },
  {
    supportedMethods: "https://example.com/pay?version=1",
  },
  {
    supportedMethods: "https://example.com/pay/version/1",
  },
];

const invalid = [
  {
    
    supportedMethods: "http://username:password@example.com/pay",
  },
  {
    
    supportedMethods: "unknown://example.com/pay",
  },
];

ユーザ・エージェントは、[URL]の等値を用いてURLベースの決済方式識別子の比較を実行しなければなりません(MUST)。

ユーザ・エージェントがURLベースの決済方式識別子をフェッチすることは、オプションです(OPTIONAL)。

標準的な決済方式識別子は、標準的な決済方式を表す文字列です。

標準的な決済方式識別子の構文を次の[ABNF]で示します。

stdpmi = part *( "-" part )
part = 1loweralpha *( DIGIT / loweralpha )
loweralpha =  %x61-7A

ユーザ・ージェントは、4. 標準的な決済方式の登録の項で挙げている0以上の標準的な決済方式識別子をサポートすることができます(MAY)。

標準的な決済方式識別子の妥当性検証を行う手順を次のアルゴリズムで示します。このアルゴリズムは、文字列を入力とし、識別子が有効である場合に真(true)を返します。

  1. 文字列が標準的な決済方式識別子の構文に適合している場合は真(true)を返します。そうでない場合は偽(false)を返します。

注

次の方式識別子は、APIで用いると、すべてユーザ・エージェントによって無視されます。一部のユーザ・エージェントは、開発者が問題を解決するのに役立つように、識別子が無効であることを通知する場合があります。

次の例では、「basic-card」という標準的な決済方式識別子を参照しています。ウェブ決済ワーキンググループはこの取り組みを中止しましたが、ここでは、この識別子を例として用いています。

例: 有効および無効な識別子 
const valid = [
  {
    supportedMethods: "basic-card",
  },
];

const invalid = [
  {
    
    supportedMethods: "basic-💳",
  },
  {
    
    supportedMethods: "Basic-Card",
  },
  {
    
    supportedMethods: "!basic-*-card!",
  },
];

標準的な決済方式識別子の場合、ユーザ・エージェントは、同一(is)を用いて文字列の比較を実行しなければなりません(MUST)。

この項は非規範的です。

標準的な決済方式とは、W3Cで標準化が行われ、このレジストリに登録されている決済方式です。

現時点では、標準的な決済方式識別子はありません。

この項は非規範的です。

サードパーティの決済ハンドラにURLベースの決済方式識別子を用いたい開発者は、決済方式マニフェスト仕様と決済方式ベスト・プラクティスwikiのページを読むことをお勧めします。これらのドキュメントは併せて、ブラウザによるジャスト・イン・タイムの決済ハンドラのインストールを含め、決済方式の承認済み決済ハンドラのエコシステムを管理する方法について説明しています。

この仕様では、セキュリティに関する新たな留意点は導入しません。

現時点では、プライバシーやセキュリティに関して留意すべき点はありません。

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「選択できる／任意である(OPTIONAL)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

[ABNF]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[fetch]
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[payment-method-manifest]
Payment Method Manifest. Dapeng(Max) Liu; Domenic Denicola; Zach Koch. W3C. 12 December 2017. W3C Working Draft. URL: https://www.w3.org/TR/payment-method-manifest/
[payment-request]
Payment Request API. Marcos Caceres; Rouslan Solomakhin; Ian Jacobs. W3C. 30 September 2021. W3C Proposed Recommendation. URL: https://www.w3.org/TR/payment-request/

↑

参照先:

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3