Extensibility_Notes

Status: This page has no Web Payments Working Group consensus. Ian Jacobs has started this page to gather notes on the topic of extensibility of the components in the Payments Request API set of specifications

Things to think about

• How to design the API so that we can extend it later in the WG. (That is: how do we avoid cutting off future possibilities?)

Payment Request API Extensibility

Requirements

• The Web Payments Working Group anticipates adding features to a future version of the API. Therefore, implementors must be able to determine which version of the API is supported by a browser.

Payment Method Extensibility

Requirements

• The Payment Method API must support diverse payment methods. Payment method inputs and outputs will vary. (We expect payment method specifications to define expected inputs and outputs.)
• The Payment Method API must enable the payer to supply custom data in addition to the data required by the payment method (for input or output).

Notes

• The group anticipates publishing a specification that describes how to use JSON-LD with the Payment Method API.
• Question: In order to support encrypted data, do we need the API spec to explicitly say base64 support is required (or something similar)?

Payment Method Identifier Extensibility

Requirements

• It must be possible for the Working Group to mint a payment method identifier for any payment method.
• It must be possible for the anyone to mint a payment method identifier for a payment method under their control.
• It should be possible to use a standard short string to identify common payment methods.
• It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.

Notes

• In practice, people may use payment method identifiers to group closely related payment methods. The API does not need to know that people are using the APIs in this way.
  • QUESTION: Should we define "not supported" semantics for payment method identifiers for cases where people are using these "broadly applicable" PMIs but want to explicitly exclude more specific ones?

Mediator Extensibility

• It may be useful (for design purposes) to distinguish the mediator role from the browser role (where the Web application runs).
• It is not a requirement that a browser support third party mediator functionality as payment applications can fulfill this role. (Browser makers have indicated in any case that they do not plan to do so.)

Payment App Extensibility

• The API must support registration of and communication with third party payment applications. (This is especially important in light of the expectation that there will unlikely be third-party mediators).
• Any mediator that knows about a registered payment app must have access to update information when that payment app is updated.
• It is not a requirement that mediators be able to read registration information from a third party application. This could be a convenience for the user by reducing the need for multiple registrations, but it is not critical path and therefore should not be part of V1 of the API in any case.