Skip to content

Spec_Notes

ianbjacobs edited this page May 18, 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)
  • Extensibility
    • Payment method specific data
    • API feature detection
  • Security
    • Top-level or with "parent" consent
  • Browser as Payment Mediator
    • Payment app registration, updates, and unregistration
    • Payment app display for selection
    • Data caching (shipping address, etc.)
    • User selection of payment app
    • Interaction with payment app (invocation, sending input data
    • Interaction with Web app (sending payment app reponse to Web app)

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

Requirements

  • Input data (Issue 157)
  • Formatting response for mediator
  • Capability Declarations
    • Supported, enabled payment methods
    • How to enable invocation of payment app when selected

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 sites (issue 109)

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.
  • Short aliases

Good Practices

  • Dereferencing

Payment Method Specifications

Requirements

  • Input data
  • Output data

Supporting Documents (not specs)

How to write a Payment Method Spec

  • Mint identifiers in those specs?
  • Flow diagram?
Clone this wiki locally