Should list of accepted payment methods be strings or objects?

[msporny]

The paymentRequest API asserts that the list of accepted payment methods that a payee exposes to the payer should be a list of strings:

http://wicg.github.io/paymentrequest/specs/paymentrequest.html#paymentrequest-interface

For example:

["visa", "bitcoin", "bobpay.com"]

The Web Payments CG Browser API asserts that the list should be composed of objects:

http://wicg.github.io/web-payments-browser-api/#processing-a-payment-request

For example:

acceptedScheme: [{
    scheme: [
      'https://w3id.org/payment-schemes#Visa',
      'https://w3id.org/payment-schemes#Mastercard',
      'https://w3id.org/payment-schemes#Discover'
    ],
    transfer: {
      amount: '4.35',
      currency: 'USD'
    },
    paymentRequestService: 'https://merchant-psp.example.com/services/getPaymentInfo'
  }, {
    scheme: 'https://w3id.org/payment-schemes#Bitcoin',
    transfer: {
      amount: '0.0177',
      currency: 'BTC'
    },
    destination: '3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC'
  },

Should list of accepted payment methods be strings or objects?

[msporny]

Should list of accepted payment methods be strings or objects?

They should be objects for at least the following reasons:

1. Different schemes require different data from the payee, which means that a strings-only approach cannot easily express all the metadata that goes along with a request.
2. Scheme metadata is usually bound very tightly to the payment request, so decoupling scheme metadata to a different parameter in the API call is probably a bad idea as that would make it more likely that the accepted schemes and the necessary data that is supposed to be used with them would get out of sync via developer error.
3. Structuring the information that goes along w/ an accepted scheme helps reduce the cognitive load on a developer.

[adrianhopebailie]

I agree that I see no value in splitting the list of supported methods and the meta-data for each method into separate parameters.

I also think the format proposed by the Web Payments CG is more flexible as it allows data such as the amount to be different for different payment methods.

The following issue is related and provides an example of a request that is something of a combination of the two: https://github.com/WICG/paymentrequest/issues/41

[dlongley]

+1 to objects for reasons stated by both @msporny and @adrianhopebailie.

[webpayments]

+1 to objects. With some minimal well defined structure and extensible.

On Thu, Dec 17, 2015 at 12:17 PM, Dave Longley notifications@github.com
wrote:

+1 to objects for reasons stated by both @msporny
https://github.com/msporny and @adrianhopebailie
https://github.com/adrianhopebailie.

—
Reply to this email directly or view it on GitHub
#37 (comment).

-Shane

[kevingordonwp]

+1 to objects. The object can still contain a parameter (called name?) that is a string of value, "visa", "bitcoin", etc, but being an object will enable additional information to be associated with that payment method. My current thinking is having this an object would be much more preferable.

[msporny]

Migrated to w3c/payment-request#48