Payment Method Identifiers

W3C Proposed Recommendation

This version:
http://www-w3-org.eastshorepartners.com/TR/2021/PR-payment-method-id-20210930/
Latest published version:
http://www-w3-org.eastshorepartners.com/TR/payment-method-id/
Latest editor's draft:
http://w3c.github.io.eastshorepartners.com/payment-method-id/
Test suite:
http://wpt.live.eastshorepartners.com/payment-method-id/
Implementation report:
http://w3c.github.io.eastshorepartners.com/test-results/payment-method-id/all.html
Previous version:
http://www-w3-org.eastshorepartners.com/TR/2021/CRD-payment-method-id-20210928/
Editor:
Marcos Cáceres (W3C)
Former editors:
Adrian Bateman (Microsoft Corporation)
Domenic Denicola (Google)
Zach Koch (Google)
Roy McElmurry (Facebook)
Participate:
GitHub w3c/payment-method-id
File an issue
Commit history
Pull requests
咪乐|类似|直播|间 两周前,我们在纽约麦迪逊大街从第59街走到第79街,我们数不清曼哈顿区有多少店面空置。

Abstract

This specification defines payment method identifiers and how they are validated, and, where applicable, minted and formally registered with the W3C. Other specifications (e.g., the Payment Request API) make use of these identifiers to facilitate monetary transactions on the web platform.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www-w3-org.eastshorepartners.com/TR/.

The working group demonstrates implementation experience by producing an implementation report. The report shows two or more independent implementations passing each mandatory test in the test suite (i.e., each test corresponds to a MUST requirement of the specification).

There has been no change in dependencies on other workings groups during the development of this specification.

This document was published by the Web Payments Working Group as a Proposed Recommendation. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification.

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Future updates to this specification may incorporate new features.

The W3C Membership and other interested parties are invited to review the document and send comments through 28 October 2021. Advisory Committee Representatives should consult their WBS questionnaires. Note that substantive technical comments were expected during the Candidate Recommendation review period that ended 01 October 2019.

This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 15 September 2020 W3C Process Document.

1. Payment method identifiers (PMIs)

A payment method identifier (PMI) is either a:

1.1 Validity

Specifications that rely on payment method identifiers MUST specify their own rules for handling invalid payment method identifiers.

The steps to validate a payment method identifier with a string pmi are given by the following algorithm. It returns true if the pmi is valid.

  1. Let url be the result of running the basic URL parser with pmi.
  2. If url is failure, validate a standardized payment method identifier with pmi and return the result.
  3. Otherwise, validate a URL-based payment method identifier passing url and return the result.

2. URL-based payment method identifiers

A URL-based payment method identifier is a URL that is valid as per the steps to validate a URL-based payment method identifier.

Note

Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Best Practice document.

2.1 Validation

The steps to validate a URL-based payment method identifier are given by the following algorithm. The algorithm takes a URL url as input and returns true if the URL is valid:

  1. If url's scheme is not "http", return false.
  2. If url's username or password is not the empty string, return false.
  3. Otherwise, return true.
Example 1: valid and invalid URL-based PMIs
const valid = [
  {
    supportedMethods: "http://example.com.eastshorepartners.com/pay",
  },
  {
    supportedMethods: "http://example.com.eastshorepartners.com/pay?version=1",
  },
  {
    supportedMethods: "http://example.com.eastshorepartners.com/pay/version/1",
  },
];

const invalid = [
  {
    // ? Uses http://, a username, and a password.
    supportedMethods: "http://username:password@example.com/pay",
  },
  {
    // ? Uses unknown URI scheme.
    supportedMethods: "unknown://example.com/pay",
  },
];

2.2 Comparison

User agents MUST perform comparisons of URL-based payment method identifiers using [URL]'s equal.

2.3 Fetching (dereferencing)

It is OPTIONAL for user agents to fetch a URL-based payment method identifier.

3. Standardized payment method identifiers

A standardized payment method identifier is a string that represents a standardized payment method.

The syntax of a standardized payment method identifier is given by the following [ABNF]:

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

User agents MAY support zero or more standardized payment method identifiers listed in section § 4. Registry of standardized payment methods.

3.1 Validity

The steps to validate a standardized payment method identifier are given by the following algorithm. The algorithm takes a string as input and returns true if the identifier is valid:

  1. Return true if string conforms to the syntax of a standardized payment method identifier. Otherwise, return false.
Note

3.2 Comparison

For standardized payment method identifiers, user agents MUST compare strings in a case-sensitive manner (code point for code point).

4. Registry of standardized payment methods

This section is non-normative.

Note

A standardized payment method is a payment method that has undergone standardization at the W3C, and is listed in this registry.

At this time there are no standardized payment method identifiers.

5. URL-based PMI and third-party payment handlers

This section is non-normative.

Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Manifest specification and the Payment Method Best Practice wiki page. Together, these documents describe how to manage the ecosystem of authorized payment handlers for a payment method, including just-in-time payment handler installation by the browser.

6. Privacy and security consideration

There are no known privacy or security concerns to be taken into considerations at this time.

7. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A. References

A.1 Normative references

[ABNF]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: http://www.rfc-editor.org.eastshorepartners.com/rfc/rfc5234
[FETCH]
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: http://fetch.spec.whatwg.org.eastshorepartners.com/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip J?genstedt; Simon Pieters. WHATWG. Living Standard. URL: http://html.spec.whatwg.org.eastshorepartners.com/multipage/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: http://www.rfc-editor.org.eastshorepartners.com/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: http://www.rfc-editor.org.eastshorepartners.com/rfc/rfc8174
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: http://url.spec.whatwg.org.eastshorepartners.com/

A.2 Informative references

[payment-method-manifest]
Payment Method Manifest. Dapeng(Max) Liu; Domenic Denicola; Zach Koch. W3C. 12 December 2017. W3C Working Draft. URL: http://www-w3-org.eastshorepartners.com/TR/payment-method-manifest/
[payment-request]
Payment Request API. Marcos Caceres; Rouslan Solomakhin; Ian Jacobs; Domenic Denicola; Adrian Bateman; Zach Koch; Roy McElmurry; Danyao Wang. W3C. 7 September 2021. W3C Candidate Recommendation. URL: http://www-w3-org.eastshorepartners.com/TR/payment-request/
百度