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: we want to be careful so that we do not hinder our ability to add features.)
• How can people provide custom data? Is it necessary to provide custom data through all arguments of the paymentRequest API or does the fourth argument suffice?

Payment App Extensibility

• The API must support registration of and communication with third party payment applications. (This is especially important if third-party mediators are uncommon).
• 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 expose (or share) registration information with other mediators. Although centralizing registration via a third party app could offer convenience for the user by reducing the need for multiple registrations, it is not critical path and therefore should not be part of V1 of the API.

Payment Method Extensibility

Requirements

• The Payment Request 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 Request 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 Request API.

Payment 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 (because payment applications can fulfill this role).

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?

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.

Notes

• Should the list of transaction types be extensible (see issue 19)?