Warning:
This wiki has been archived and is now read-only.

Payment Architecture Priorities

From Web Commerce Interest Group
Jump to: navigation, search

Payment Capabilities v1

Basic Payment Request/Invoice
Minimum Requirements
  • invoice includes: acceptable payment schemes, amount, currency, vendor name, vendor tracking number
  • non-forgeable (digital signature on invoice)
  • extensible data format to support other information in invoice in the future
Limitations
  • no description of product or offer
Use Cases
Basic Payment Service Provider Discovery
Minimum Requirements
  • Re-direct browser to PSP-based Payment Agent to process invoice
Limitations
  • No ability to register local wallet apps
  • No payment message router functionality (to route invoices to appropriate local or cloud payment agent)
Use Cases
Basic Payment Agent
Requirements
  • route invoice from merchant site to payment service provider
  • route proof from payment service provider to merchant site
  • don't expose any identity information if not required for transaction
Limitations
  • cloud-only payment agents (no device-local / native app payment agents)
  • polyfill implementation (no native browser support, yet)
Use Cases
Basic Proof of Payment
Requirements
  • crypto-token to establish trust that funds are on their way to the merchant (EMVCo token)
  • extensible data format to allow for different types of proofs in the future
  • digital signatures/crypto of some kind to prevent forgeries
Limitations
  • credit card only (EMVCo tokens)
Use Cases
Basic Product Delivery
Requirements
  • deliver product to customer either virtually or physically
Limitations
  • No advanced features like shipping address encryption
Use Cases
Basic Credentials
Requirements
  • protocol for storing and transmitting credentials
  • machine readability
  • digital signatures on credential
Limitations
  • this work is not in the critical path for Payment Architecture
  • this work is performed in another group in parallel to the PAWG
Use Cases

Payment capabilities v2

Detailed Offers
Requirements
  • machine-readable product and service offers
  • non-forgeable (digital signature on offer by merchant)
  • easily index-able by search engines
Limitations
  • limited set of vocabulary terms
  • Re-use Good Relations / schema.org vocabulary where applicable
Use Cases
Coupons and Discounts
Requirements
  • Storage of coupons via Payment Agent
  • Transmission of coupons via Payment Agent
Limitations
  • none
Use Cases
Loyalty Payment Instruments
Requirements
  • storage of scheme
Limitations
Use Cases
Subscription Payments
Requirements
  • payment scheme token provided to merchant that can be re-used on a periodic basis
Limitations
Use Cases
Basic Post-purchase Actions
Requirements
  • deliver electronic or physical receipt
  • initiate a refund request
Limitations
  • No advanced features like detailed receipt/summary
Use Cases

Payment capabilities v3

Parametric Offers
Requirements
  • Parametric and algorithmic offers (pricing variables read from live data sources)
  • Transmission of offers via wireless channels
Limitations
  • None
Use Cases
Advanced Payment Agent
Requirements
  • Programmatic selection of best payment instrument for transaction
  • Knowledge of regulation and reporting requirements and action based on requirements
  • Push payments (payer-initiated payments)
Limitations
  •  ???
Use Cases
NFC / BTLE Communication
Requirements
  • Support Payment Architecture v1 and v2 over short-range wireless links
Limitations
  • none?
Use Cases
Strong Multi-factor Authentication
Requirements
  • support generic multi-factor authentication
Limitations
  • not in critical path for Payment Architecture work, happens in parallel in W3C/IETF/GSMA security/crypto groups
Use Cases
Advanced Credentials
Requirements
  • multi-level KYC support (thumbprint credentials, cell number credentials, facial image credentials, etc.)
  • privacy-enhancing credentials (proof of age, encrypted shipping address, etc.)
  • high-stakes credentials (professional licenses, law enforcement credentials, criminal background checks, etc.)
Limitations
  • this work is not in the critical path for Payment Architecture
  • this work is performed in another group in parallel to the PAWG
Use Cases

Payment capabilities v4

  • Decentralized ledger technology for settlement/clearing
Decentralized ledgers
Requirements
  • settlement and clearing through ledgers
Limitations
Use Cases
Algorithmic Contracts
Requirements
  • Programmatic creation of new payment schemes / networks
Limitations
Use Cases
  • NONE - Missing use cases
Currency Conversion and Foreign Exchange
Requirements
Limitations
Use Cases
  • NONE - Missing use cases
Delivery and Shipping
Requirements
Limitations
Use Cases
  • NONE - Missing use cases
Automated Regulatory Reporting
Requirements
Limitations
Use Cases
  • NONE - Missing use cases
Taxation
Requirements
Limitations
Use Cases
  • NONE - Missing use cases

Uncategorized

  • Credentials and Authorization
    • Multi-level KYC
    • Portable KYC
    • Privacy-enhancing credentials (proof of age, shipping address, etc.)
  • Wallet and Payment Instrument Provisioning and Administration
  • Security and Auditing

Use Cases

Commentary

  • Include access from native applications in v1
    • "We wouldn’t need to provide a registration API for native apps, since the operating system will handle that for us automatically based upon the app’s manifest. The same could be true for web based implementations. The Web Apps WG is currently standardising a JSON based manifest for web apps. A further possibility is via the web page markup, e.g. metadata declared in the HTML HEAD." (DSR)
    • The barrier for implementing this broadly in v1 is very high, I suggest we only support cloud-based solutions in v1 and then support native apps in v2 --Manu Sporny (talk) 05:14, 7 May 2015 (UTC)
  • Dependencies
    • Authentication. Expect dependencies on new authentication WGs (DSR)
    • Digital signatures. Will they depende on specific payment instruments? (DSR)
      • Many of the payment instruments that exist today have no digital signatures to prevent forgeries. We need some way of enabling signature-less schemes to be used on the Web (basically, by enabling payment service providers or the payment networks to digitally sign payment approval messages).
  • Proof of payment
    • "I question whether the new WG would need to standardise the proof of payment as this would normally be defined by the standards applicable to each payment instrument." DSR)
    • Most payment instruments don't have a "proof of payment". You just rely on your payment service provider to be truthful, which is fine in payee-initiated payment scenarios. It is not fine in payer-initiated payment scenarios (a merchant can't trust that their customer is telling the truth when it comes to moving money). --Manu Sporny (talk) 05:14, 7 May 2015 (UTC)
  • Routing of requests from merchants to payment services providers.
    • "Same...this would normally be defined by the standards applicable to each payment instrument." DSR)
      • This is only true in payee-initiated payments. It is not true for payer-initiated payments. --Manu Sporny (talk) 05:14, 7 May 2015 (UTC)