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

[tommythorsen]

@adrianhopebailie

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.

I think we are going to have problems enforcing this. If I put myself in the shoes of a payment app developer: why would I not register all of my supported payment methods as enabled all the time? Even if the user hasn't registered a payment instrument in my app yet, I can lead him through the instrument registration process as part of the payment process.

That way, the user gets to buy his thing without being told ERROR: NO MATCHING PAYMENT APP, and I get to make some money off the transaction. Everybody wins! (Except for the users that have many payment apps installed, only some of which have suitable payment instruments registered, but all showing up in the payment app selector regardless).

[adrianhopebailie]

I think we are going to have problems enforcing this.

I don't think we have to enforce this but we should point it out in the spec so apps can differentiate IF they need to. In the proposed spec I worded this as:

"If a payment app defines a payment method as enabled then it MUST be able to process any payment request that lists that payment method as supported"

So as long as the payment app believes it can handle the request it can set the method as enabled (that includes if the app is able to enroll the necessary instrument on the fly).

What we are trying to avoid is apps that advertise payment methods that have a high chance of failing because then the website has to resubmit the request and start the process again.

[tommythorsen]

@adrianhopebailie
Now that I read the proposed text again, it does indeed allow for this case, but maybe the text could be clearer in stating that an instrument does not necessarily have to be registered for a method for it to be put in the enabled list, as long as it's easy to do so on the fly.

Another thing that I think might be confusing with the current text is that it mentions the supported state of a payment method as if it was a concrete state, but it's not. supported is an entirely abstract concept, meaning that the payment method is not in the enabled list, but it could potentially have been, if the user had configured it so.

Let's look again at (part of) the original question:

Merchant supports C.

Does browser match on C and display it, even though the user has no relevant payment instrument?

If we take "Merchant supports C" to mean "C is supported, but not enabled", then matching on C is impossible, as supported payment methods are not actually listed anywhere and can't be matched on by the mediator.

I'll try to make a PR that makes these things a bit clearer.

[adrianhopebailie]

@tommythorsen

If we take "Merchant supports C" to mean "C is supported, but not enabled", then matching on C is impossible, as supported payment methods are not actually listed anywhere and can't be matched on by the mediator.

Correct. The mediator should not match on C because that would result in the mediator passing the request to a payment app that will likely reject it which is the worst case scenario because then the whole flow has to start again

[ianbjacobs]

@adrianhopebailie wrote:

"If a payment app defines a payment method as enabled then it MUST be able to process any payment request that lists that payment method as supported"

My first observation is that is a requirement on payment apps. In previous conversations you had said you were trying to think about conformance only for browsers (which I don't mind as a project). I just want to point out this would be an exception.

My second is that I don't think we should include that requirement. Here's why:

• The requirements for conformance to a payment method should be part of the payment method spec, not the payment app spec.
• I don't believe that we should tightly couple the definition of "enabled" as it relates
  to matching, with processing.
• In general, I don't think we need requirements of the form "if you say you do it, you have
  to do it." Rather, we need statements that simply add up to conformance: "Do X. Do Y."

Meanwhile, we have listed a number of requirements related to the display of payment apps and the selection of payment apps:

• https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#payment-app-display-by-the-browser
• https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#payment-app-selection-by-the-user

In that list is this requirement:

• The user must be able to select any displayed payment app.
• Selection of a recommended (but unregistered) payment app should lead to payment app registration before invocation.

Note that "displayed payment app" is defined in the wiki to be: "a matching or recommended payment app presented by the browser for user selection."

...and there are definitions of "matching" and "recommended" payment apps etc.

We have not agreed yet to support "recommended payment apps" but the topic has
come up and so I've put some ideas about them in the wiki.

Ian

[adrianhopebailie]

My first observation is that is a requirement on payment apps. In previous conversations you had said you were trying to think about conformance only for browsers (which I don't mind as a project). I just want to point out this would be an exception.

My second is that I don't think we should include that requirement

👍 - I haven't yet incorporated the edits you and I discussed. I don't think this should be normative text. It is supposed to be guidance for payment app developers to ensure they understand the distinction and don't register themselves with browsers in a way that will lead to many abandoned transactions.

I only referenced the current text here to point out to @tommythorsen that the intent is for payment apps to decide which methods they support are enabled and that they can do this based on their own logic as long as they only list a payment method as enabled if they believe they will be able to handle a payment request for that payment method and any enrollment that may be required can be done on the fly.

[ianbjacobs]

Migrating to superset issue:
w3c/payment-handler#38