Status: These are notes from Ian Jacobs on Web Payments WG spec organization. These are intended for discussion and do not represent group consensus.

See also:

• Payment App Notes
• Payment Method Identifier Notes
• Extensibility Notes

Payment Request

Requirements

• Input data
  • Supported payment method identifiers
  • Amounts (variable per payment method)
  • Data caching (shipping address, etc.)
• Extensibility
  • Payment method specific data
  • API feature detection
• Security
  • Top-level or with "parent" consent

Potential Requirements

• Unsupported payment methods as input data
  • This is only useful if we support grouping/subclassing

Good practice

• Secure data through encryption and signatures (issue 141)

Payment Apps in the Browser

Requirements

• Input data (Issue 157)
• Formatting response for mediator
• Capability Declarations
  • Supported, enabled payment methods
  • How to enable invocation of payment app when selected
• Browser as Payment App Mediator *
  • Payment app registration, update, unregistration
  • Payment app display for selection
  • User selection of payment app
  • Interaction with payee (sending payment method response data to Web app)

* Note: Ian prefers not to create a separate mediator spec at this time.

Potential Requirements

• Specification by the payee of required data in the response (which may be a subset of all data specified by the payment method). (Issue 97)
• Explicit statement of unsupported payment methods
  • This is only useful if we support grouping/subclassing
• Standard mechanism for payment apps to communicate with Web services (issue 109)
• Recommended payment apps (by merchant or browser)

Good practice

• Extensibility
  • Payment apps provide app version information

Payment Method Identifiers

Requirements

• Extensibility
  • The group has decided to use absolute URLs
• Identifier Syntax
  • The group has decided to use absolute URLs
• Identifier Matching Algorithm
  • Rationale: This algorithm must be understood by both browsers/mediator developers and payment app developers (who announce what they support).

Potential Requirements

• Grouping/Subclassing semantics
  • If we support those, consider explicit "Unsupported" semantics as well, including in matching algorithm.

Good Practices

• Dereferencing

Non requirements

• Short aliases
  • The WG has resolved not to include short aliases in V1

Payment Method Specifications

Requirements

• Input data
• Output data

Supporting Documents (not specs)

Big Picture

• How the various pieces work together.

How to write a Payment Method Spec

• Mint identifiers in those specs?
• Flow diagram?

How to write a Payment App

• Should help people address common scenarios.