Add section on Extensibility

[msporny]

Migrating from w3c/webpayments#27:

The Web Payments WG resolved to specify how extensibility of messages is handled in the API specifications to something that looks like this:

"""
In general, the WebIDL descriptions provided in this specification outline the specific interfaces, properties, and values that an implementation may depend on. It is expected that other properties and values will be stored in objects that implement the various interfaces in this specification (e.g. PaymentApplication, PaymentRequest, PaymentAcknowledgement, etc.). While this specification does not suggest a single extension mechanism, it does anticipate extensibility. To that end, Implementations MUST preserve unrecognized properties and their associated values.
Another specification [LINK_TBD] explains how to extend the parameters used with this API using JSON-LD.

ISSUE XYZ: The Working Group seeks feedback from the Web community on that specification and how well it furthers interoperability needs in the payments ecosystem. To provide feedback, see the status section above.
"""

[adrianba]

How can you tell if an implementation preserved unrecognised values or not? What would a test for this look like?

[halindrome]

Ahh! As it turns out I have been working on this. It is pretty straightforward. We will supply a skeletal payment app that communicates with the test management system's server. Custom code on the server will evaluate the messages that are passed to the payment app from the user agent to ensure the messages adhere to the structure that was input. So we can evaluate the basic parameters, and also ensure that the data passed through is untouched.

A separate communication channel from the test case to the server (web sockets and service worker) will send /down/ the success criteria, and will receive /up/ a message from the server indicating the success or failure of the evaluation.

[msporny]

+1 @halindrome - that's how we've tested stuff like this in the past via our JSON-LD tests (and it is pretty simple to test).

[adrianhopebailie]

The mechanism for data in a PaymentRequest to be extended is through payment method specific data.

[msporny]

There is still no section on extensibility in the specification. -1 on closing this issue.

[adrianhopebailie]

@msporny I believe that this will be captured in the Payment Method Identifiers spec so this list is not the right place for this issue.

If you disagree and have some text you consider appropriate for this spec please submit a PR.