Abstract

The Payment Request API [PAYMENT-REQUEST-API] requires that merchants supply a list of identifiers for supported payment methods. This specification defines those identifier strings and how they are created.

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 https://www.w3.org/TR/.

The working group maintains a list of all bug reports that the group has not yet addressed. This draft highlights some of the pending issues that are still to be discussed in the working group. No decision has been taken on the outcome of these issues including whether they are valid. Pull requests with proposed specification text for outstanding issues are strongly encouraged.

This specification was derived from a report published previously by the Web Platform Incubator Community Group.

This document was published by the Web Payments Working Group as a Working Draft. This document is intended to become a W3C Recommendation. Comments regarding this document are welcome. Please send them to public-payments-wg@w3.org (subscribe, archives).

Publication as a Working Draft 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.

This document was produced by a group operating under the 5 February 2004 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 1 March 2017 W3C Process Document.

1. Introduction

This section is non-normative.

To use Payment Request API, merchants (or their service providers) must know how to handle payment method specific data for those methods they claim to accept. This allows the API to abstract away the details of specific payment methods and to add new ones over time without changing the API specification.

As part of using Payment Request API, the Web page provides an array of strings that identify accepted payment methods. This specification defines those strings.

2. Dependencies

This specification relies on several other underlying specifications.

URL
The terms URL, absolute URL, base URL, URL parser, URL equivalence, special scheme, scheme, host, port, path, query, and fragment are defined by [url-1-20141209] (or the editor's draft).
Secure Contexts
The term potentially trustworthy URL is defined by the Secure Contexts specification [SECURE-CONTEXTS].

3. URLs as Payment Method Identifiers

When the party responsible for a payment method wishes to publish machine-readable information associated with the payment method, it does so with a URL. This URL approach offers at least two benefits: identifier decentralization and origins as a trust mechanism. In particular, owners of proprietary payment methods can use Web servers under their control to publish security information about authorized payment apps.

Issue 1: Payment method manifest specification in progress
The Web Payments Working Group is developing a payment method manifest specification for the information a payment method owner would want to publish. Payment method identifiers that are URLs will help user agents locate these manifest files using a mechanism defined in that specification. Payment Manifest Proposal.
Issue 2: URL maintenance and performance
Either in the payment method manifest specification or in separate "good practice" documentation, the Working Group should address issues of server performance for payment method identifiers that are URLs. Furthermore, when parties feel they do not need to publish a manifest, we should explain that a manifest with an explicit machine-readable assertion that "any payment app may implement" is preferable to lack of a manifest.

3.1 Syntax

When URLs are used for payment method identifiers they MUST be absolute URLs including, at most, a scheme, host, port and path. The URL must be a potentially trustworthy URL as defined in the [SECURE-CONTEXTS] specification. Identifier URLs MUST have null query and fragment values.

3.2 Matching

User agents MUST use the following algorithm to determine whether two payment method identifiers that are URLs match:

4. W3C-Defined Strings as Payment Method Identifiers

W3C expects to publish a small number of payment method specifications that define abstractions across similar payment methods (such as credit card payments, tokenized payments, or credit transfers). W3C expects these payment methods will be implemented in a wide variety of third party payment apps. W3C identifies these payment methods with (short) strings; W3C expects to mint these strings in payment method specifications published by the Web Payments Working Group.

4.1 Syntax

The syntax of W3C strings used as payment method identifiers is constrained by this regular expression:

          [a-z0-9-]+
        

4.2 Matching

For W3C strings, user agents MUST use exact string matching.

5. Conditional Matching Beyond Payment Method Identifier Matching

For some payment methods, merchants may wish to express that they accept a payment method but only under certain conditions (e.g., "I only credit cards from brand A and debit cards from brand B"). The Web Payments Working Group has discussed several ways to support more sophisticated matching beyond initial payment method identifier matching.

A. References

A.1 Normative references

[PAYMENT-REQUEST-API]
Payment Request API. Adrian Bateman; Zach Koch; Roy McElmurry.W3C Working Draft. URL: https://www.w3.org/TR/payment-request/
[url-1-20141209]
URL. Anne van Kesteren; Sam Ruby. W3C. 9 December 2014. W3C Working Draft. URL: https://www.w3.org/TR/2014/WD-url-1-20141209/

A.2 Informative references

[SECURE-CONTEXTS]
Secure Contexts. Mike West. W3C. 15 September 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/secure-contexts/