Re: [w3c/webpayments] Registration: App supports method but user has no instrument for that method (#110)

@halindrome I see where you and @dlongley are coming from but consider the fact that a payment app may be a mobile app from the App Store or Play Store or even an embedded component of Web of Things device.

The original architecture I wrote up in the wiki explicitly defined Payment Apps and the Payment Mediator as roles. That means you can only prescribe so much or you begin limiting the ways that role can be implemented.

I define the role of Payment App as simply "able to accept payment requests and return payment responses and advertise the payment methods it is able to process".

The HTTP API can take that further and define what those capabilities mean when the interface is an HTTP client/server connection. The browser API specification will either leverage the HTTP API to describe how the request and response go from the user agent to a web based payment app or it might describe a purely browser API based interface.

But, I don't see a place for us to ever define any more specifics about payment apps. Their internal processing is implicitly (or explicitly) defined by the publishers of the payment method specs that they claim to support.

The W3C can write general guidance on how web apps SHOULD behave to improve interoperability and accessibility but we should be careful about defining a special class of web app and then giving it additional conformance criteria beyond the implicit requirements of any web app.

---
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/webpayments/issues/110#issuecomment-210122716