Update "user accepts the payment request algorithm" to include interaction with payment app

[adrianhopebailie]

There is an inconsistency in the spec between the description of PaymentResponse.details and user accepts the payment request algorithm

The description of PaymentResponse.details includes the following:

This data is returned by the payment app that satisfies the payment request.

However the algorithm is short on detail about:

1. How the user will select a payment app (it only talks about accepting a payment request)
2. How the UA will pass the payment request to the payment app
3. How the UA will get the payment response back from the payment app

This is related to issues #50 and #39 but is here to track the spec changes required once these questions have been answered.

[adrianba]

This is implementation specific and should not be further defined in this specification.

[adamroach]

This is implementation specific and should not be further defined in this specification.

I agree that this is probably true for the first item ("How the user will select a payment app"), but I think the second and third items need addressing. It's not clear to me whether they go in here or in the payment app spec, though. (I think this highlights the importance of not advancing this spec ahead of the payment app spec, BTW, as we'll need to have things like this kept in sync between them)

[adrianhopebailie]

This is implementation specific

I strongly disagree with this, as the discussion around apps to date shows there is a strong desire to, at least, define standardized behavior of browsers to interface to payment apps over the Web.

Even if the details of the browser to payment app interaction is delegated to another document there remains an inconsistency between these two parts of this document which makes the whole flow unclear.

Either the reference to payment apps in PaymentResponse.details should be removed or the algorithm should be updated to, at a minimum, describe where the interaction with a payment app would occur in the steps.

[dlongley]

I think "user accepts the payment request algorithm" may need to be renamed -- I agree with @adamroach that how the user selects a Payment App is likely implementation specific, but many of the interactions thereafter (with the Payment App) are not.

"User agent sends payment request message to Payment App and receives payment response message algorithm" is a bit lengthy, but that's really the part that needs to be specified so there's appropriate interop with payment apps.

[adrianba]

I believe the spec adequately addresses everything needed for a user agent to support payment apps. It deliberately doesn't need to specify what it means for a user to accept a payment request and whether this happens with an interaction to a payment app or through some other means. Once the user has accepted the request including picking and approving payment with a specific method then the algorithm runs.

I've heard there is a desire for people to write a spec for developing and deploying platform independent payment apps using web technologies. That's a fine aspiration and something we should explore especially as it validates the design that we have. However that belongs in a separate document.

There's also the issue of whether there should be a platform independent way of discovering and registering payment apps. We should write this specification too but again it is a separate document.

[adrianhopebailie]

Once the user has accepted the request including picking and approving payment with a specific method then the algorithm runs.

This is a fundamental departure from flow the group already agreed to. The user doesn't approve the payment or pick the payment method in the user agent.

The user picks a payment app in the user agent, which may support multiple payment methods that are common to those supported in the request.

Only once the user is interacting with the payment app do they pick the payment method they'd like to use (if necessary) and approve the payment.

[ianbjacobs]

Only once the user is interacting with the payment app do they pick the payment method they'd like to use (if necessary) and approve the payment.

That is my understanding as well.

Ian

[burdges]

It's important the user picks the payment app because uninvolved payment apps should not be notified that a payment is taking place. Anything else becomes a security nightmare.

[adrianba]

The "user accepts the payment request algorithm" runs after any user interaction including running any payment apps has already happened. Recommend closing this issue.

[adrianhopebailie]

The "user accepts the payment request algorithm" runs after any user interaction including running any payment apps has already happened.

👍