Skip to content

Spec_Notes

webpayments-specs edited this page Jun 1, 2016 · 45 revisions

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 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.
Clone this wiki locally