From Web Commerce Interest Group
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 |
|
Use Cases |
|
Loyalty Payment Instruments |
|
Requirements |
|
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 |
|
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 |
|
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 |
|
Currency Conversion and Foreign Exchange |
|
Requirements |
|
Limitations |
|
Use Cases |
|
Delivery and Shipping |
|
Requirements |
|
Limitations |
|
Use Cases |
|
Automated Regulatory Reporting |
|
Requirements |
|
Limitations |
|
Use Cases |
|
Taxation |
|
Requirements |
|
Limitations |
|
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
- 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)