Migrated from w3c/webpayments#18:

Are the core set of payment messages extensible?

If they are extensible, what is the extensibility mechanism?

Is the browser required to understand this extensibility mechanism?

This was partially resolved (via WG resolution) in the Web Payments CG spec via this language:

http://wicg.github.io/web-payments-browser-api/#extensibility

Also, the API allows for payment-method specific data.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#paymentrequest-constructor

See also this issue about feature detection:
#33

I suggest we close this issue.

Ian

-1 to closing the issue because of the following reasons:

1. The spec doesn't have a section that talks about extensibility of messages.
2. There is no way to get to the 'data' object that is passed into the PaymentRequest constructor.

It's currently left unspecified how any of this payment-method specific data finds its way to a payment app.

I believe point one is covered by
#44

@ianbjacobs agreed that point 1 is covered by #44. I was responding to the "close this issue", which we shouldn't do until there is a PR that's been accepted that covers 1 and 2 above.

Extensibility is covered by #44. The developer accesses data using their own code.

var data = { ... };
var request = new PaymentRequest(a,b,c,data);
//TODO: use data here

developer accesses data using their own code.

Where is it specified how the payment app gets access to that information? A native payment app? What about a web-based payment app?

Extensibility is covered by #44.

For some very limited definition of extensibility. I'm asserting that not everything about extensibility is covered by #44 and there is nuance here that we need to discuss as a group.

We still haven't had the discussion around extensibility that the Web Payment CG specs raised via the Messaging spec (see PaymentRequest) here:

http://web-payments.github.io/web-payments-messaging/#payment-request

@msporny wrote:

"Where is it specified how the payment app gets access to that information? A native payment app? What about a web-based payment app?"

Is that question registered as issue 50?
#50

Ian

@ianbjacobs,

Is that question registered as issue 50?

Partially -- that may cover native payment apps, but not web-based payment apps. The Web Payments CG spec specified a mechanism by which web-based payment apps received a payment request message (which are extensible by nature).

I maintain that a web-based payment app is an essential requirement for this API. The alternative is native thin payment apps that communicate with their web service outside of our context. I mean - that is what is going to happen anyway with any native payment app IMHO, but there is no reason I can think of to require that sort of an architecture. A payment app (read web app) should be able to register a URI that gets invoked using messaging we define for the various interactions we require.

Please note the resolution taken by the group on this issue:
w3c/webpayments#83

We require an explicit conformance criteria that guarantees that if a website passes unknown properties or attributes in the payment request that these will be received by the payment app.

We don't yet have the extensibility document which we resolved to create and link to, so the approved issue text doesn't make sense yet but an issue marker in the same vein should be added.

In TAG review @triblondon said:

would that [non payment method specific data] be data specific to a payment app then? AFAICT, the merchant doesn't know about payment apps, only payment methods, so it's hard to see how custom data not tied to a payment method could be useful. The issue is a bit unclear on what the core problem is here.

Comment cited here is from @triblondon instead of me

The spec doesn't have a section that talks about extensibility of messages.

Addressed by #44.

There is no way to get to the 'data' object that is passed into the PaymentRequest constructor.

Partially addressed by #50 for the case of native payment apps.

The unresolved and unaddressed aspects of this issue have been forked to #146