How do organizations layer additional information in the core messages?

[msporny]

If we have a core set of payment messages, are they extensible?

If they are extensible, what is the extensibility mechanism?

Is the browser required to understand this extensibility mechanism?

[msporny]

If we have a core set of payment messages, are they extensible?

Yes, developers should be able to encapsulate arbitrary information into the core payment messages.

If they are extensible, what is the extensibility mechanism?

Linked Data should be the extensibility mechanism. Specifically, JSON-LD.

Is the browser required to understand this extensibility mechanism?

No, the browser (nor most developers) need to understand the extensibility mechanism. However, there does need to be one and JSON-LD provides a mechanism that looks a great deal like JSON w/o having the extensibility issues that JSON has.

[msporny]

From Payment Request Architecture

For example, we expect multiple different payment apps to support returning credit card PANs and they should all do so using the same field names.

This seems to imply either:

a) A registry of JSON field names, or
b) A JSON-LD context and Linked Data vocabulary that specifies those field names, their expected types, usage, etc.

Strong +1 for the latter, since there are many other considerations when attempting to create common registries and do decentralized extensibility other than just the names of the fields themselves. Lots of people have put a great deal of thought into b) after failing (to various degrees) at a).

[msporny]

From Payment Request Architecture:

If we choose to support well-known short strings for payment methods then we will need to determine where to define them. We may choose to define these well-known strings in a formal specification.

You can have well-known short strings for payment methods via a JSON-LD Context (another reason to use JSON-LD). For example, this is easy to do:

{
  "@context": "https://w3c.org/vocabs/payments/v1",
  "type": "PaymentInstrument",
  "method": "Visa",
  "paymentService": "https://psp.example.com/pay"
}

which formally means (via a JSON-LD Context):

  "https://w3c.org/vocabs/payments#method": "https://visa.com/vocabs#Visa"
  "https://w3c.org/vocabs/payments#paymentService": "https://psp.example.com/pay"

No danger of conflicts, formal meaning for what "Visa" means, and the benefit that the browser nor developers need to care about those details (they use the markup at the top, which looks more or less like JSON, which they're used to).

[dlongley]

+1 to JSON-LD context w/ well-known short strings. Has both the advantage that machines can process it and that developers don't need to care about it if they don't want to.

[adrianhopebailie]

I am not convinced of the need for decentralised extensibility of the messages.

The message extensions will be defined by the publishers of a payment method specification and the implementors of that payment method will reference that specification.

It's possible that the developers of a payment method specification may choose to use JSON-LD for their payment method so that it can be arbitrarily extended by others but that would be a special case for that payment method.

I worry that if we say the messages use JSON-LD but also say:

Is the browser required to understand this extensibility mechanism?

No, the browser (nor most developers) need to understand the extensibility mechanism.

Then we run the risk of developers assuming they can use the full features of JSON-LD or passing the JSON-LD data through a library that de-references keys or similar and outputs valid JSON-LD but the browser or PSP that consumes it is unable to parse it because they are not treating it as JSON-LD.

[msporny]

Migrated to w3c/payment-request#40