From 412ebb7e6f1d9f67c8627addd43be2748188aeca Mon Sep 17 00:00:00 2001 From: Roy McElmurry Date: Mon, 15 Aug 2016 19:35:27 -0700 Subject: [PATCH] update pmi spec with apen and proprietary payment method identifiers --- index.html | 74 +++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 62 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index cb95287..4424529 100644 --- a/index.html +++ b/index.html @@ -1,4 +1,3 @@ - Payment Method Identifiers @@ -46,6 +45,36 @@ ] , status: "WD" }, + "BASIC-CARD-PAYMENT": { + title: "Basic Card Payments" + , href: "https://w3c.github.io/webpayments-methods-card/" + , authors: [ + "Adrian Bateman" + , "Zach Koch" + , "Richard Barnes" + , "Roy McElmurry" + ] + }, + "SEPA-CREDIT-TRANSFER": { + title: "SEPA Credit Transfer" + , href: "http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/" + , authors: [ + "Cyril Vignet" + , "Matt Saxon" + ] + }, + "PAYMENT-APPS": { + title: "Payment App API" + , href: "https://w3c.github.io/webpayments-payment-apps-api/" + , authors: [ + "Adrian Hope-Bailie" + , "Tommy Thorsen" + , "Adam Roach" + , "Jason Normore" + , "Ian Jacobs" + ] + , status: "WD" + }, "REVERSE-DOMAINS": { title: "Reverse Domain Name Notation" , href: "https://en.wikipedia.org/wiki/Reverse_domain_name_notation" @@ -95,17 +124,36 @@

Dependencies

URL
The terms URL, absolute URL, base URL, URL parser, and URL equivalence are defined by [[!url-1-20141209]] (or the editor's draft).
+
+

Do we need a reference to some URN spec?

+

Payment Method Identifier

- The Payment Method Identifier is a string that uniquely identifies a payment method that a user can use to complete a transaction. For example, Visa, MasterCard, and American Express are payment methods used in some countries. + The Payment Method Identifier is a string that uniquely identifies a payment method that a user can use to complete a transaction. For example, Visa, MasterCard, and American Express are payment methods used in some countries. These identifiers are split into two categories that take different forms.

+
-

Identifier format

-

Payment method identifiers are strings containing a URL. The string MUST be an absolute URL.

+

Open Identifier Format

+

Ubiquitous payment methods such as [[!BASIC-CARD-PAYMENT]] and [[!SEPA-CREDIT-TRANSFER]] are documented by the Web Payments Working Group through corresponding paymenth method specifications that also describe the inputs and outputs of those payment methods. Each open payment method is identified by a URN. This URN is purely an identifier, it does not resolve to anything. Open payment method identifiers should have the format:

+ 
+urn:payment-method:{name}
+
+

where name is the payment method's name. Any changes made to these payment methods over time must be approved by consensus of the Web Payments Working Group.

+ +
+

Proprietary Identifier Format

+

Many payment methods are naturally proprietary. Only one party is able to process payments with that payment method. These payment methods are not documented by the Web Payments Working group through formally published payment method specifications. It is instead the responsibility of the party supporting that payment method to define its behavior and input and output data.

+

These proprietary payment methods are identified with an absolute URL.

+ 
+https://roypay.foo/pay
+
+

By default, [[!PAYMENT-APPS]] other than those associated with the identifying origin cannot claim to offer support for these payment methods. For example, http://bobpay.xyz/pay cannot support the paymeth method identified by https://roypay.foo/pay. Payment mediators must not recognize payment app as supporting a proprietary payment method unless the payment app originates from the same origin as the payment method identifier.

+
+

Identifier equivalence

When the PaymentRequest API is invoked, the web page provides a list of identifiers for supported payment methods. @@ -129,14 +177,16 @@

Issues

The following issues are tracking aspects of the payment method identifier specification:

-
-

A registration mechanism may exist to install the code for new payment methods into the user agent. This process - would add support for a new payment method to the user agent. This mechanism should be defined in a separate specification.

-

There is an initial outline making a proposal.

-
- -
-

There is an open issue about whether payment method identifiers should resolve to a resource if they are URLs.

+
+

This proposal does not necessarily assume that anything should exist at the identifying URL, but it is probably really useful to do so. The WG should consider standardizing what this optional thing could look like (e.g. a manifest file containing information about the payment method).

+

The benefit of the above approach is that it provides a mechanism for the identifying origin to assert what other origins could potentially also support that payment method.

+

For example, let's say that RoyPay is a proprietary payment method, but RoyPay has struck a deal with AlicePay to also allow AlicePay to return back valid RoyPay payment responses. We could define a mechanism to support this within the manifest file located at roypay.foo/pay:

+ 
+{
+  name: 'http://roypay.foo/pay',
+  supportedOrigins: ['https://alicepay.xyz'],
+}
+