We need a PaymentAppResponseData dictionary

[tommythorsen]

When the payment mediator invokes a payment app, it does not pass the PaymentRequest instance to the app. Instead it passes a PaymentAppRequestData structure (as defined here).

Likewise, when the payment app passes response data back to the mediator, it should use a PaymentAppResponseData structure instead of creating a PaymentResponse. I have two reasons for this:

1. Symmetry. The more symmetrical we can make the request and response, the easier it will be for developers to understand and use the API.
2. Serializability. The data that is passed between the mediator and the payment app needs to be json-serializable. The complete method of the PaymentResponse makes this object not serializable.

I have assigned this issue to myself, and unless I'm hearinging objections to the addition of this structure, I plan to make a PR soon.

[tommythorsen]

I propose that PaymentAppResponseData look something like this:

dictionary PaymentAppResponseData {
    DOMString paymentRequestID;
    DOMString methodName;
    object details;
};

[tommythorsen]

I created PR #84 for this. As I was making the change, I couldn't really see any reason for having the paymentRequestID property in this dictionary, so it has been omitted, leaving methodName and details.

There might be a point in having paymentRequestID in the PaymentAppRequestData dictionary, since the payment app might need to know this ID, but since it shouldn't be able to change the ID, there is no point having it in PaymentAppResponseData.

[ianbjacobs]

I'm ok with omitting it.

Ian

[ianbjacobs]

We closed this issue today by adopting PR #84