Fixes #48.
PR #162 refactored the supportedMethods and payment specific data
fields. Issue #3 discusses supporting multiple currencies and issue #4
discusses price per payment method and we should consider specific
proposals for those issues.
PR #162 replaces the `sequence<DOMString>` with
`sequence<PaymentMethodData>` so we now use objects.
Fixes #48.
PR #162 refactored the supportedMethods and payment specific data
fields. Issue #3 discusses supporting multiple currencies and issue #4
discusses price per payment method and we should consider specific
proposals for those issues.
PR #162 replaces the `sequence<DOMString>` with
`sequence<PaymentMethodData>` so we now use objects.
Fixes #48.
PR #162 refactored the supportedMethods and payment specific data
fields. Issue #3 discusses supporting multiple currencies and issue #4
discusses price per payment method and we should consider specific
proposals for those issues.
PR #162 replaces the `sequence<DOMString>` with
`sequence<PaymentMethodData>` so we now use objects.
Migrated from w3c/webpayments#37:
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:
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:
Should list of accepted payment methods be strings or objects?