# Payment Method Manifest

## Editor’s Draft, 1 January 1970

This version:
  https://w3c.github.io/payment-method-manifest/
Latest published version:
  https://www.w3.org/TR/payment-method-manifest/
Editors:
  Dapeng Liu (Alibaba)
  Domenic Denicola (Google) d@domenic.me
  Zach Koch (Google)

Copyright © 1970 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

## Abstract

This specification defines the machine-readable manifest file, known as a payment method manifest, describing how a payment method participates in the Web Payments ecosystem, and how such files are to be used.

## Status of this document

## 1. Introduction

This section and its sub-sections are non-normative.

### 1.1. Use cases

This specification intends to address the following use cases:

- The owner of a payment method wishes to authorize only certain parties to distribute payment apps that are capable of implementing the payment method. In this use case, the browser helps to ensure that for that payment method, the user can only invoke payment apps from parties authorized by the owner of the payment method.

- In addition, the owner of a payment method wishes to confirm the authenticity of a particular payment app (e.g., via a digital signature for that app).

- When the user has not yet installed a payment app for a payment method, the user agent can provide an improved user experience for procuring one.

This is accomplished via the requirement that every payment method whose identifier is URL-based will provide a payment method manifest file in JSON format containing two key pieces of information:

- any default payment apps that are associated with this payment method, referenced as absolute-URL strings giving the URL of their web app manifests; and

- any other origins that are permitted to return payment credentials for this payment method.

### 1.2. Accessing the manifest

The machine-readable payment method manifest might be found either directly at the payment method identifier URL, or in a location indicated indirectly by following a HTTP ``Link`` header from that URL. [RFC8288]

This potential indirection allows the use of generic, human-readable URLs (such as "`https://alicepay.com/`") to serve as payment method identifiers, while still locating the actual payment method manifest at a different URL.

For an example payment method AlicePay, with payment method identifier "`https://alicepay.com/`", a user agent would issue a GET request to that payment method identifier URL as follows:

    GET / HTTP/2
    Host: alicepay.com
    User-Agent: Mellblomenator/9000

The server could then either respond with

    HTTP/2 204
    Link: </pay/payment-manifest.json>; rel="payment-method-manifest"

to redirect the user agent to "`https://alicepay.com/pay/payment-manifest.json`", or could respond with the JSON contents of the payment method manifest directly in a `200`-status response.

### 1.3. Example manifest file

Continuing our example from § 1.2 Accessing the manifest, the AlicePay payment method could provide the following payment method manifest file at `https://alicepay.com/pay/payment-manifest.json`:

    {
      "default_applications": ["app/webappmanifest.json"],
      "supported_origins": [
        "https://bobpay.xyz",
        "https://alicepay.friendsofalice.example"
      ]
    }

This indicates that, if the user agent does not have a payment app for AlicePay installed, it can locate one by consulting the web app manifest at "`https://alicepay.com/pay/app/webappmanifest.json`".

It also indicates that, apart from this default payment app, AlicePay also allows payment apps hosted at the two indicated origins to be used for AlicePay. This means that if the user agent ever encounters payment apps hosted at those origins claiming support for AlicePay, it can allow them to act as payment apps for the AlicePay payment method.

The manifest file could also omit the "`supported_origins`" key, if no third-party payment apps are supported for the payment method in question, or it could use the value "`*`" instead of an array of origins, to indicate that any third party is allowed to support the payment method.

## 2. Manifest format

A valid payment method manifest file is a UTF-8 encoded file containing contents parseable as a JSON object. The resulting JSON object must contain at most two items, with the possible keys "`default_applications`" and "`supported_origins`".

The value of the `default_applications` key, if present, must be a non-empty JSON array. Each item in the array must be a valid URL string such that the resulting URL's scheme, when parsed against the URL of the payment method manifest, is "`https`".

The value of the `supported_origins` key, if present, must be either the string "`*`", or a non-empty JSON array. In the latter case, each item in the array must be an absolute-URL string that represents an HTTPS origin. Formally, the string must be equal to the serialization of the resulting parsed URL's origin.

Web developers must ensure that all of their payment method manifests are valid.

As with all conformance requirements on the contents of files, these are web-developer facing, and not implementer-facing. The exact processing model (given in § 3 Processing model) governs how implementers process all payment method manifest files, including invalid ones.

The following payment method manifest is not valid, but the currently-specified processing model algorithms will still accept it:

    {
      "default_applications": ["app/webappmanifest.json"],
      "created_by": "Alice",
      "created_in": "Wonderland"
    }

This could change in the future, for example if the processing model later expands to define a meaning for a new standard "`created_by`" key that requires it to be an object instead of a string. To avoid situations like this, web developers are best served by ensuring validity of their payment method manifests, and thus avoiding any unpleasant surprises.

## 3. Processing model

### 3.1. Modifications to Payment Request API

This specification integrates with the rest of the Payment Request ecosystem by modifying the `PaymentRequest(methodData, details, options)` constructor. It adds the following steps, before the algorithm completes and returns the newly-constructed `PaymentRequest` object. In what follows, let request be the `PaymentRequest` instance being constructed. [PAYMENT-REQUEST]

1. Let identifiers be a list consisting of the first item of each pair in request.[[serializedMethodData]].

2. Let client be the current settings object.

3. Ingest payment method manifests given identifiers and client.

These steps are what kicks off the whole process. The rest of § 3 Processing model is concerned with defining how this process eventually leads to new payment apps being available for the user.

As this specification gains multi-implementer interest, we anticipate moving this section into the Payment Request API specification itself, instead of maintaining a monkeypatch here.

### 3.2. Ingesting payment method manifests

Given a list of payment method identifiers identifiers, as well as an environment settings object client, the user agent may run the following steps, to ingest payment method manifests:

1. Fetch payment method manifests, given identifiers and client, and wait for this to asynchronously complete with manifestsMap. If the result is failure, return.

2. For each identifierURL → (responseURL, manifest) of manifestsMap:

   1. Let parsed be the result of validating and parsing manifest given responseURL. If this returns failure, continue.

   2. For each webAppManifestURL in parsed’s default applications:

      1. Fetch the web app manifest at webAppManifestURL given identifierURL and client, and wait for it to asynchronously complete with webAppManifestString. If the result is failure, continue.

      2. Let webAppManifest be the result of running the steps for processing a web app manifest given webAppManifestString.

         The steps for processing a web app manifest are very forgiving and will return empty objects or objects missing crucial fields instead of failing. User agents will need to separately validate the processed web app manifest to ensure it contains enough data for their purposes in the next step.

      3. In a user-agent-specific way, use the resulting processed web app manifest webAppManifest to install any applicable payment apps for the payment method identified by identifier.

         In the future, the plan is for there to be a user-agent-independent way to use the resulting processed web app manifest, by consulting its `serviceworker` field and using that to install a web-based payment app conforming to the Payment Handler API specification. [PAYMENT-HANDLER]

   3. Associate the supported origins to identifier so that the user agent can use it in the future to determine what third-party payment apps can be displayed for the payment method identified by identifier.

### 3.3. Fetching payment method manifests

To fetch payment method manifests, given a list of JavaScript strings supportedMethods and an environment settings object client, perform the following steps. This algorithm will asynchronously complete with a map (possibly empty) from URLs to (URL, byte sequence) tuples, mapping payment method identifiers to the URL and contents of the corresponding manifest.

1. Let identifierURLs be an empty list.

2. For each string of supportedMethods:

   1. Let identifierURL be the result of basic URL parsing string. If the result is failure, continue.

      The result will be failure for any payment method identifier that is not a URL-based payment method identifier, i.e. for a standardized payment method identifier.

   2. If validating identifierURL returns false, continue.

   3. Optionally, continue.

      This step allows implementations to skip any of the provided payment method identifiers for user-agent-specific reasons. § 4 Security and privacy considerations discusses some reasons why user agents might prefer to only ingest certain identifiers.

   4. Append identifierURL to identifierURLs.

3. Let manifestsMap be an empty map.

4. For each identifierURL of identifierURLs:

   1. Let manifestURLString be null.

   2. Let identifierRequest be a new request whose method is ``GET``, url is identifierURL, client is client, mode is "`cors`", credentials mode is "`omit`", redirect mode is "`error`", and referrer policy is "`strict-origin-when-cross-origin`".

   3. Fetch identifierRequest.

      To process response with the response identifierResponse:

      1. If identifierResponse is a network error or identifierResponse’s status is not an ok status, continue.

      2. Let linkHeaders be the result of extracting header list values given ``Link`` and identifierResponse’s header list.

      3. For each linkHeader of linkHeaders:

         1. Parse linkHeader according to the `link-value` production. If it cannot be parsed, continue. [RFC8288]

         2. If the parsed header contains a parameter whose name is an ASCII case-insensitive match for the string "`rel`" and whose value is an ASCII case-insensitive match for the string "`payment-method-manifest`", then set manifestURLString to the string given by the `URI-Reference` production in the parsed header, and break.

      4. If manifestURLString is not null, then:

         1. Terminate the ongoing fetch of identifierRequest (since the body will not be needed).

         2. Let manifestURL be the result of basic URL parsing manifestURLString with base URL given by identifierResponse’s url. If the result is failure, continue.

         3. If manifestURL’s scheme is not "`https`", continue.

         4. Let manifestRequest be a new request whose url is manifestURL, client is client, referrer is identifierResponse’s url, mode is "`cors`", credentials mode is "`omit`", and redirect mode is "`error`".

         5. Fetch manifestRequest. To process response end-of-body with the response manifestResponse:

            1. If manifestResponse is a network error or manifestResponse’s status is not an ok status, continue.

            2. Let body be manifestResponse’s body.

            3. If body is null, continue.

            4. Let reader be the result of getting a reader from body.

            5. Let promise be the result of reading all bytes from body with reader.

            6. Upon fulfillment of promise with a byte sequence bytes, set manifestsMap[identifierURL] to (response’s URL, bytes).

      To process response end-of-body with the response identifierResponse:

      1. If manifestURLString is not null, continue.

      2. Let body be identifierResponse’s body.

      3. If body is null, continue.

      4. Let reader be the result of getting a reader from body.

      5. Let promise be the result of reading all bytes from body with reader.

      6. Upon fulfillment of promise with a byte sequence bytes, set manifestsMap[identifierURL] to (identifierResponse’s URL, bytes).

5. Once all ongoing fetch algorithms initiated by the above steps are complete, including the specified process response and process response end-of-body steps, asynchronously complete this algorithm with manifestsMap.

### 3.4. Validating and parsing payment method manifests

A parsed payment method manifest is a struct containing two fields:

default applications

  An ordered set of URLs, possibly empty

supported origins

  Either the string "`*`", or an ordered set of origins

To validate and parse a byte sequence bytes purporting to contain a payment method manifest, given a URL url, perform the following steps. The result will either be a parsed payment method manifest, or failure.

1. Let string be the result of UTF-8 decoding bytes.

2. Let parsed be the result of parsing JSON into Infra values given string. If this throws an exception, return failure.

3. If parsed is not an ordered map, return failure.

4. Let defaultApps be an empty ordered set.

5. If parsed["`default_applications`"] exists:

   1. Let defaultAppsValue be parsed["`default_applications`"].

   2. If defaultAppsValue is not a list, return failure.

   3. If the size of defaultAppsValue is 0, return failure.

   4. For each defaultApp in defaultAppsValue:

      1. If defaultApp is not a string, return failure.

      2. Let defaultAppURL be the result of basic URL parsing defaultApp, given the base URL url. If the result is failure, return failure.

      3. If defaultAppURL’s scheme is not "`https`", return failure.

      4. Append defaultAppURL to defaultApps.

6. Let supportedOrigins be an empty ordered set.

7. If parsed["`supported_origins`"] exists:

   1. Let supportedOriginsValue be parsed["`supported_origins`"].

   2. If supportedOriginsValue is "`*`", set supportedOrigins to "`*`".

   3. Otherwise:

      1. If supportedOriginsValue is not a list, return failure.

      2. If the size of supportedOriginsValue is 0, return failure.

      3. For each supportedOrigin in supportedOriginsValue:

         1. If supportedOrigin is not a string, return failure.

         2. Let supportedOriginURL be the result of basic URL parsing supportedOrigin. If the result is failure, return failure.

         3. If supportedOriginURL’s scheme is not "`https`", return failure.

         4. If supportedOriginURL’s username or password are not the empty string, return failure.

         5. If supportedOriginURL’s path's size is not 0, return failure.

         6. If supportedOriginURL’s query or fragment are not null, return failure.

         7. Append supportedOriginURL’s origin to supportedOrigins.

8. Return a new parsed payment method manifest with default applications given by defaultApps and supported origins given by supportedOrigins.

Empty arrays for "`default_applications`" or "`supported_origins`" will cause parsing to fail. That is, this is not a valid payment method manifest, and will be rejected by the above algorithm:

    {
      "default_applications": ["https://alicepay.com/pay/app/webappmanifest.json"],
      "supported_origins": []
    }

### 3.5. Fetching web app manifests

Because the determination of payment apps happens independent of any embedding HTML document, the procedure for obtaining a web app manifest that gives information about a default payment app is different from the usual steps for obtaining a web app manifest.

To fetch the web app manifest for a default payment app, given a URL url, a URL referrer, and an environment settings object client, perform the following steps. This algorithm will asynchronously complete with either a scalar value string or failure.

1. Let request be a new request whose url is url, client is client, referrer is referrer, mode is "`cors`", credentials mode is "`omit`", and redirect mode is "`error`".

2. Fetch request. To process response end-of-body with the response response:

   1. If response is a network error or response’s status is not an ok status, asynchronously complete this algorithm with failure.

   2. Let body be response’s body.

   3. If body is null, asynchronously complete this algorithm with failure.

   4. Let reader be the result of getting a reader from body.

   5. Let promise be the result of reading all bytes from body with reader.

   6. Upon fulfillment of promise with a byte sequence bytes, asynchronously complete this algorithm with the result of UTF-8 decoding bytes.

   7. Upon rejection of promise, asynchronously complete this algorithm with failure.

## 4. Security and privacy considerations

### 4.1. Revealing user activity to payment providers

Ingesting payment method manifests might reveal information to a payment service about the activity of an end user. For example, a payment method that is only supported on one website might allow that payment provider to discover the IP addresses of users who visit that website.

One way to mitigate this is to fetch the manifests only for the payment apps that the user has installed or has explicitly expressed interest in. This confines the risk to only sharing the user’s IP address with those parties.

Another important mitigation is already built in to the spec, by setting the appropriate referrer policy and referrer on the various fetches performed here. These requirements ensure that only the server that controls the identifier URL will see the user’s activity, and even then will only see the origin of the web page that is creating the `PaymentRequest` object (instead of seeing the full URL).

### 4.2. Considerations for development environments

In development situations, a user agent might lower the security requirements of this specification to ease testing. For example, the requirements in the fetch payment method manifests and validate and parse the payment method manifest algorithms requiring a "`https`" scheme might be dropped in a development environment. In such situations, the user agent is intentionally not complying with this specification, and should notify the user of the reduced security.

### 4.3. Matching payment apps

<https://github.com/w3c/payment-method-manifest/issues/11>

## 5. IANA considerations

### 5.1. The `payment-method-manifest` link relation

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Relation name

  payment-method-manifest

Description

  Links to a payment method manifest, which describes a specific payment method within the Web Payments ecosystem.

Reference

  https://w3c.github.io/payment-method-manifest/

Notes

  See § 3.3 Fetching payment method manifests for the specific manner in which such links are expected to be fetched, and § 3.2 Ingesting payment method manifests for the larger context in which they are used.

## Acknowledgments

§ 3 Processing model is based heavily on algorithms originally outlined by Rouslan Solomakhin.

Thanks to Andrew Betts, Anne van Kesteren, Ian Jacobs, L. David Baron, Marcos Cáceres, and Rouslan Solomakhin for their contributions to making this specification awesome!

## Index

### Terms defined by this specification

- default applications, in §3.4
- fetch payment method manifests, in §3.3
- fetch the web app manifest for a default payment app, in §3.5
- ingest payment method manifests, in §3.2
- parsed payment method manifest, in §3.4
- payment method manifest, in §Unnumbered section
- supported origins, in §3.4
- valid, in §2
- validate and parse the payment method manifest, in §3.4
- validity, in §2
- valid payment method manifest, in §2

https://www.w3.org/TR/appmanifest/#dfn-processed-manifest Referenced in:

- 3.2. Ingesting payment method manifests (2) (3)

https://www.w3.org/TR/appmanifest/#dfn-obtaining-the-manifest Referenced in:

- 3.5. Fetching web app manifests

https://www.w3.org/TR/appmanifest/#dfn-processing-a-manifest Referenced in:

- 3.2. Ingesting payment method manifests (2)

https://www.w3.org/TR/appmanifest/#dfn-manifest-url Referenced in:

- 1.1. Use cases

https://www.w3.org/TR/appmanifest/#dfn-manifest Referenced in:

- 1.1. Use cases
- 1.3. Example manifest file
- 3.5. Fetching web app manifests

https://encoding.spec.whatwg.org/#utf-8 Referenced in:

- 2. Manifest format

https://encoding.spec.whatwg.org/#utf-8-decode Referenced in:

- 3.4. Validating and parsing payment method manifests
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-response-body Referenced in:

- 3.3. Fetching payment method manifests (2) (3)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-request-client Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-request-credentials-mode Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#extract-header-list-values Referenced in:

- 3.3. Fetching payment method manifests

https://fetch.spec.whatwg.org/#concept-fetch Referenced in:

- 3.3. Fetching payment method manifests (2) (3)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-get-reader Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-response-header-list Referenced in:

- 3.3. Fetching payment method manifests

https://fetch.spec.whatwg.org/#concept-request-method Referenced in:

- 3.3. Fetching payment method manifests

https://fetch.spec.whatwg.org/#concept-request-mode Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-network-error Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#ok-status Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#process-response Referenced in:

- 3.3. Fetching payment method manifests (2)

https://fetch.spec.whatwg.org/#process-response-end-of-body Referenced in:

- 3.3. Fetching payment method manifests (2) (3)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-read-all-bytes-from-readablestream Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-request-redirect-mode Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-request-referrer Referenced in:

- 3.3. Fetching payment method manifests
- 3.5. Fetching web app manifests
- 4.1. Revealing user activity to payment providers

https://fetch.spec.whatwg.org/#concept-request-referrer-policy Referenced in:

- 3.3. Fetching payment method manifests
- 4.1. Revealing user activity to payment providers

https://fetch.spec.whatwg.org/#concept-request Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-response Referenced in:

- 3.3. Fetching payment method manifests (2) (3)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-response-status Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://fetch.spec.whatwg.org/#concept-fetch-terminate Referenced in:

- 3.3. Fetching payment method manifests

https://fetch.spec.whatwg.org/#concept-response-url Referenced in:

- 3.3. Fetching payment method manifests (2) (3) (4)

https://html.spec.whatwg.org/multipage/webappapis.html#current-settings-object Referenced in:

- 3.1. Modifications to Payment Request API

https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object Referenced in:

- 3.2. Ingesting payment method manifests
- 3.3. Fetching payment method manifests
- 3.5. Fetching web app manifests

https://html.spec.whatwg.org/multipage/origin.html#concept-origin Referenced in:

- 1.1. Use cases
- 1.3. Example manifest file (2)
- 2. Manifest format
- 3.4. Validating and parsing payment method manifests
- 4.1. Revealing user activity to payment providers

https://html.spec.whatwg.org/multipage/origin.html#ascii-serialisation-of-an-origin Referenced in:

- 2. Manifest format

https://infra.spec.whatwg.org/#set-append Referenced in:

- 3.4. Validating and parsing payment method manifests (2)

https://infra.spec.whatwg.org/#ascii-case-insensitive Referenced in:

- 3.3. Fetching payment method manifests (2)

https://infra.spec.whatwg.org/#iteration-break Referenced in:

- 3.3. Fetching payment method manifests

https://infra.spec.whatwg.org/#byte-sequence Referenced in:

- 3.3. Fetching payment method manifests (2) (3)
- 3.4. Validating and parsing payment method manifests
- 3.5. Fetching web app manifests

https://infra.spec.whatwg.org/#iteration-continue Referenced in:

- 3.2. Ingesting payment method manifests (2)
- 3.3. Fetching payment method manifests (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)

https://infra.spec.whatwg.org/#map-exists Referenced in:

- 3.4. Validating and parsing payment method manifests (2)

https://infra.spec.whatwg.org/#list-iterate Referenced in:

- 3.2. Ingesting payment method manifests (2)
- 3.3. Fetching payment method manifests (2) (3)
- 3.4. Validating and parsing payment method manifests (2)

https://infra.spec.whatwg.org/#struct-item Referenced in:

- 3.1. Modifications to Payment Request API

https://infra.spec.whatwg.org/#javascript-string Referenced in:

- 3.3. Fetching payment method manifests

https://infra.spec.whatwg.org/#list Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.4. Validating and parsing payment method manifests (2)

https://infra.spec.whatwg.org/#ordered-map Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.4. Validating and parsing payment method manifests

https://infra.spec.whatwg.org/#ordered-map Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.4. Validating and parsing payment method manifests

https://infra.spec.whatwg.org/#ordered-set Referenced in:

- 3.4. Validating and parsing payment method manifests (2) (3) (4)

https://infra.spec.whatwg.org/#parse-json-into-infra-values Referenced in:

- 3.4. Validating and parsing payment method manifests

https://infra.spec.whatwg.org/#scalar-value-string Referenced in:

- 3.5. Fetching web app manifests

https://infra.spec.whatwg.org/#map-set Referenced in:

- 3.3. Fetching payment method manifests (2)

https://infra.spec.whatwg.org/#list-size Referenced in:

- 3.4. Validating and parsing payment method manifests (2) (3)

https://infra.spec.whatwg.org/#struct Referenced in:

- 3.4. Validating and parsing payment method manifests

https://infra.spec.whatwg.org/#tuple Referenced in:

- 3.3. Fetching payment method manifests

https://w3c.github.io/payment-method-id/#dfn-payment-method-identifiers Referenced in:

- 1.1. Use cases
- 1.2. Accessing the manifest (2) (3) (4)
- 3.2. Ingesting payment method manifests
- 3.3. Fetching payment method manifests (2) (3)

https://w3c.github.io/payment-method-id/#dfn-standardized-payment-method-identifiers Referenced in:

- 3.3. Fetching payment method manifests

https://w3c.github.io/payment-method-id/#dfn-url-based-payment-method-identifiers Referenced in:

- 1.1. Use cases
- 3.3. Fetching payment method manifests
- 4.1. Revealing user activity to payment providers

https://w3c.github.io/payment-method-id/#dfn-validate-a-url-based-payment-method-identifier Referenced in:

- 3.3. Fetching payment method manifests

https://w3c.github.io/payment-request/#dom-paymentrequest Referenced in:

- 3.1. Modifications to Payment Request API (2)
- 4.1. Revealing user activity to payment providers

https://w3c.github.io/payment-request/#dfn-paymentrequest-paymentrequest Referenced in:

- 3.1. Modifications to Payment Request API

https://w3c.github.io/payment-request/#dfn-serializedmethoddata Referenced in:

- 3.1. Modifications to Payment Request API

https://w3c.github.io/payment-request/#dfn-payment-apps Referenced in:

- 1.1. Use cases (2) (3)
- 1.3. Example manifest file (2) (3)
- 3.1. Modifications to Payment Request API
- 3.2. Ingesting payment method manifests (2) (3)
- 3.5. Fetching web app manifests
- 4.1. Revealing user activity to payment providers

https://w3c.github.io/payment-request/#dfn-payment-method Referenced in:

- Unnumbered Section
- 1.1. Use cases (2) (3) (4) (5) (6)
- 1.2. Accessing the manifest
- 1.3. Example manifest file (2) (3)
- 3.2. Ingesting payment method manifests (2)
- 4.1. Revealing user activity to payment providers
- 5.1. The payment-method-manifest link relation

https://www.w3.org/2001/tag/doc/promises-guide/#upon-fulfillment Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.5. Fetching web app manifests

https://www.w3.org/2001/tag/doc/promises-guide/#upon-rejection Referenced in:

- 3.5. Fetching web app manifests

https://url.spec.whatwg.org/#absolute-url-string Referenced in:

- 1.1. Use cases
- 2. Manifest format

https://url.spec.whatwg.org/#concept-basic-url-parser Referenced in:

- 3.3. Fetching payment method manifests (2)
- 3.4. Validating and parsing payment method manifests (2)

https://url.spec.whatwg.org/#concept-url-fragment Referenced in:

- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#concept-url-origin Referenced in:

- 2. Manifest format
- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#concept-url-password Referenced in:

- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#concept-url-path Referenced in:

- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#concept-url-query Referenced in:

- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#concept-url-scheme Referenced in:

- 2. Manifest format
- 3.3. Fetching payment method manifests
- 3.4. Validating and parsing payment method manifests (2)
- 4.2. Considerations for development environments

https://url.spec.whatwg.org/#concept-url Referenced in:

- 2. Manifest format (2)
- 3.3. Fetching payment method manifests (2) (3)
- 3.4. Validating and parsing payment method manifests (2)
- 3.5. Fetching web app manifests

https://url.spec.whatwg.org/#concept-url-username Referenced in:

- 3.4. Validating and parsing payment method manifests

https://url.spec.whatwg.org/#valid-url-string Referenced in:

- 2. Manifest format

### Terms defined by reference

- [appmanifest] defines the following terms:
  - processed web app manifest
  - steps for obtaining a web app manifest
  - steps for processing a web app manifest
  - url
  - web app manifest
- [ENCODING] defines the following terms:
  - utf-8
  - utf-8 decode
- [FETCH] defines the following terms:
  - body
  - client
  - credentials mode
  - extract header list values
  - fetch
  - get a reader
  - header list
  - method
  - mode
  - network error
  - ok status
  - process response
  - process response end-of-body
  - read all bytes
  - redirect mode
  - referrer
  - referrer policy
  - request
  - response
  - status
  - terminated
  - url (for response)
- [HTML] defines the following terms:
  - current settings object
  - environment settings object
  - origin
  - serialization of an origin
- [INFRA] defines the following terms:
  - append (for set)
  - ascii case-insensitive
  - break
  - byte sequence
  - continue
  - exist
  - for each
  - item
  - javascript string
  - list
  - map
  - ordered map
  - ordered set
  - parse json into infra values
  - scalar value string
  - set
  - size
  - struct
  - tuple
- [payment-method-id] defines the following terms:
  - payment method identifier
  - standardized payment method identifier
  - url-based payment method identifier
  - validate a url-based payment method identifier
- [PAYMENT-REQUEST] defines the following terms:
  - PaymentRequest
  - PaymentRequest(methodData, details, options)
  - [[serializedmethoddata]]
  - payment app
  - payment method
- [promises-guide] defines the following terms:
  - upon fulfillment
  - upon rejection
- [URL] defines the following terms:
  - absolute-url string
  - basic url parser
  - fragment
  - origin
  - password
  - path
  - query
  - scheme
  - url
  - username
  - valid url string

## References

### Normative References

[APPMANIFEST]
  Marcos Caceres; et al. Web App Manifest. URL: https://w3c.github.io/manifest/
[ENCODING]
  Anne van Kesteren. Encoding Standard. Living Standard. URL: https://encoding.spec.whatwg.org/
[FETCH]
  Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
  Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[PAYMENT-METHOD-ID]
  Marcos Caceres; et al. Payment Method Identifiers. URL: https://w3c.github.io/payment-method-id/
[PAYMENT-REQUEST]
  Zach Koch; et al. Payment Request API. URL: https://w3c.github.io/payment-request/
[PROMISES-GUIDE]
  Domenic Denicola. Writing Promise-Using Specifications. 9 November 2018. TAG Finding. URL: https://www.w3.org/2001/tag/doc/promises-guide
[RFC8288]
  M. Nottingham. Web Linking. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[URL]
  Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/

### Informative References

[PAYMENT-HANDLER]
  Adrian Hope-Bailie; et al. Payment Handler API. URL: https://w3c.github.io/payment-handler/

#payment-method-manifest Referenced in:

- 1.1. Use cases
- 1.2. Accessing the manifest (2)
- 1.3. Example manifest file
- 2. Manifest format (2) (3) (4)

#valid-payment-method-manifest Referenced in:

- 2. Manifest format (2) (3)
- 3.4. Validating and parsing payment method manifests

#ingest-payment-method-manifests Referenced in:

- 3.1. Modifications to Payment Request API
- 4.1. Revealing user activity to payment providers

#fetch-payment-method-manifests Referenced in:

- 3.2. Ingesting payment method manifests
- 4.1. Revealing user activity to payment providers
- 4.2. Considerations for development environments

#parsed-payment-method-manifest Referenced in:

- 3.4. Validating and parsing payment method manifests (2)

#parsed-payment-method-manifest-default-applications Referenced in:

- 3.2. Ingesting payment method manifests
- 3.4. Validating and parsing payment method manifests

#parsed-payment-method-manifest-supported-origins Referenced in:

- 3.2. Ingesting payment method manifests
- 3.4. Validating and parsing payment method manifests

#validate-and-parse-the-payment-method-manifest Referenced in:

- 3.2. Ingesting payment method manifests
- 4.2. Considerations for development environments

#fetch-the-web-app-manifest-for-a-default-payment-app Referenced in:

- 3.2. Ingesting payment method manifests