Registration: App supports method but user has no instrument for that method

[ianbjacobs]

User registers a payment app that supports payment methods A, B, and C. But user does not register any payment instruments for method C. Merchant supports C.

Does browser match on C and display it, even though the user has no relevant payment instrument?
Should the payment app be prepared to deal with that scenario and inform the user (or invite the user to register a payment instrument)?

Should the browser not match on C?
Should there be other behavior?

[adrianhopebailie]

Should the browser not match on C?

No

Should there be other behavior?

The way apps interact with the mediator (browser/mobile OS) should allow them to regularly update which methods they support so that when they are initially installed they don't advertise support for any payment methods that the user doesn't have a payment instrument for. (See #111)

So in this example, the app technically supports payment methods C (i.e. it understands the messages and requirements) but it is not able to process payments using that method therefor it should not register itself as supporting method C until the user loads a payment instrument that enables that.

[mattsaxon]

How does the user know that the app supports this payment instrument? Might the merchant want to encourage the user to register with it, for example so a relevant coupon could be used during the purchase?

I propose that it should be possible to a merchant to query information about its 'affiliated' payment applications such that it can guide the user through this.

This looks like the discussion in issue #112

[corwinAmbre]

I have a similar question for you. If I have a payment app 1 which supports methods A, B and another payment app 2 which supports methods B and C. Will the instrument B need to be registered again in second payment application or will there be any mechanism to share it, avoiding providing payment information again?
I'm mainly thinking about credit cards here as there are many providers and users will need to provide card information for all PSP if not shared (which won't be the case for Paypal for instance).

[ianbjacobs]

@corwinAmbre,

Will the instrument B need to be registered again in second payment application or will there be any mechanism to share it, avoiding providing payment information again?

It is my understanding that the Working Group does not plan to address (or standardize) how people provide credentials to payment apps.

Ian

[adrianhopebailie]

It is my understanding that the Working Group does not plan to address (or standardize) how people provide credentials to payment apps.

+1 - this is out of scope for the W3C to prescribe.

[dlongley]

@adrianhopebailie,

+1 - this is out of scope for the W3C to prescribe.

To be clear, you mean it's out of scope for this WG, correct? W3C may take up work elsewhere to address sharing credentials.

[adrianhopebailie]

No, I mean the W3C should not be defining conformance criteria for payment apps. We have defined how they fit into our architecture and how components that we do define conformance criteria for (like user agents) should behave when interfacing with them but no more.

How those payment requests and responses are processed, including how a user selects the credentials to use in a credential based payment method is for the designers of that payment method to define (if they consider it as a requirement for stated support of that payment method).

I accept that W3C might have a generic credential sharing mechanism that we recommend web applications use in future but we can't (and shouldn't) prescribe that payment apps use it.

[halindrome]

@adrianhopebailie you will be shocked to hear that I have an opinion on this ;-)

First, the APA is producing a Payments Accessibility User Requirements document, and I trust that in the fullness of time the W3C will require its support. This will include some requirements on Payment Apps (in that they must be accessible).

Second, as to credentials... well, it would be good if the W3C required that every piece of the ecosystem were able to grok the same sort of "verifiable claims". Attributes about payers are something I expect will be part of that ecosystem. So... I guess I agree with you today, but tomorrow I might not. And it would be good if we avoided precluding the more robust environment.

[adrianhopebailie]

@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.

[halindrome]

Gotcha. When talking about accessibility, things are always couched in conditionals (e.g., when the payment app presents a user interface that allows for the selection from a list of one or more payment methods, that list must be exposed in such a way that assistive technologies can ensure the list is selectable by users with visual and/or motor skill challenges). So I don't think we are disagreeing on that point.

I agree about internal processing... I think. It might be nice to suggest messaging structures that would improve their interoperability and ease of use in the case of push payments, for example.

[adrianhopebailie]

when the payment app presents a user interface that allows for the selection from a list of one or more payment methods

This is a good example of what I don't think we should be saying at all 😄

We don't care HOW payment apps work. All we require of payment apps is that they accept a payment request and return a response (and make it possible to query which methods they support).

If somebody defines a payment method and an app claims to support that method then it's the person/company/scheme that defines the method that will care about the HOW.

If that app happens to support many methods then the way they help users choose which one to use is a payment app thing.

One caveat is that we may define an algorithm for ordering or preference that we recommend they follow but I'm not sure how we would ever plan to "enforce" that given that we are hoping for there to be 100's of different payment apps out there.

At the end of the day we need to remember that payment apps are chosen by the user. So if they suck the user will choose another one. Hopefully our architecture creates a level-playing field so that market forces really do force payment apps to be either awesome or obsolete.

[burdges]

It's fine if both (a) the payment app can reject the request and throw the user back to the mediator, and (b) the user can backup fro the payment app into the payment mediator, like if they do not like the results or the payment app is buggy, etc.

I suspect the harder issue might be : Can a payment reject being an option for a particular transaction before the user even gets presented with the option? To do that, a payment app would need to register a javascript filter with the payment mediator.

[ianbjacobs]

@adrianhopebailie,

We don't care HOW payment apps work. All we require of payment apps is that they accept a payment request and return a response (and make it possible to query which methods they support).

I have been thinking that as well. However, I do think some good practice material is in order, and being able to revise it as we learn more. That good practice material could include examples of how to write an app for different payment methods, security considerations, accessibility considerations, etc.

Ian