Re: [w3c/browser-payment-api] Merged PaymentRequest params and tweaked to address some issues (#133)

> @@ -284,16 +284,77 @@
>            payment app.
>          </div>
>          <div class="note">
> -          <p>The <code>supportedMethods</code> sequence contains the <a>payment method identifiers</a>
> -          for the <a>payment methods</a> that the merchant web site accepts.</p>
> +
> +          <p>The <code>details</code> contains the core payment request data that will be passed on to the user selected
> +            <a>payment app</a>.</p>
> +
> +          <p>The <code>amount</code> sequence contains the amount (possibly in different currencies) that the website
> +            is requesting to be paid.</p>
> +
> +          <p>The <code>supportedMethods</code> sequence contains the <a>payment methods</a> that the merchant web
> +            site accepts. Each <a>payment method</a> is linked to one or more <a>payment method identifiers</a>.</p>
> +
> +          <p>The <code>identifers</code> sequence contains the <a>payment method identifiers</a> that identify the
> +          <a>payment methods</a> the web site supports and for which the associated <code>data</code> is part of the

> I don't think it should be defined as WebIDL at all (See #132).

+1 for NOT using WebIDL. It's overkill for what we're trying to do and not very helpful for non-browser environments.

> What do you suggest?

I'm working on a VERY ROUGH proposal for a payment message data model and syntax-specific validation mechanism here:

http://msporny.github.io/webpayments/proposals/core-messages/#the-data-model

That might be ready to talk about in a day or two...

Instead of "data", just allow data to be placed into each "supportedMethod" w/o an encapsulating container. The downside there is the potential for a developer to use a common term like "account" in the wrong way (term conflicts). The upside being that we get rid of all of those "data" containers.

I'm not convinced that the risk of term conflicts is high enough for us to worry about it. Keep in mind that developers will know what goes in the payment method specific messages because there will be specs with well defined schemas (with limits expressed in English and perhaps even JSON Schema). If they use JSON-LD, this is a non-issue as you're almost guaranteed not to conflict.

In any case, I hope to have a more solid proposal/alternative to "data" in the next day or two. Again, please merge the PR even w/ "data" in there as well as the "amount" concerns as I like this approach more than what's in the current spec.

I'll make a separate PRs to take "data" out once I get the messages proposal in a bit better shape.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/133/files/38f22264a20bbe3dcaaa3d47036d9c08c07237fc#r59234926