search

w3c / webpayments

The document repo for the Web Payments Working Group
https://github.com/w3c/webpayments/wiki
Other
257 stars 63 forks source link

Overview document figure 5 #171

Closed rvm4 closed 3 years ago

rvm4 commented 8 years ago

In figure 5 of the overview document (https://w3c.github.io/webpayments-overview/) we have a step where the Payee communicates the success of an out-of-band tokenized card payment back to the mediator. Why do we have this step? I don't think we need to suggest that the Payee pipe their transactions back to the mediator.

rsolomakhin commented 8 years ago

The mediator shows a spinner to the user while the transaction is processing. It can have words like "Loading..." or "Processing transaction...". When the website notifies the mediator that the transaction is complete, the mediator can let the user know what happened in a consistent manner. For example, in case of failure, the mediator can show an error message. In case of success, the mediator can show a "Transaction processed" message or quietly hide the spinner.

halindrome commented 8 years ago

Shouldn't it be the payment app that is controlling the experience at that point, not the mediator?

rvm4 commented 8 years ago

The payment app is done at this point in the flow. In the example of this diagram the payment app has already returned a tokenized credential to the payee. At this point I think the mediator's involvement is done. We have no way of knowing how the payee will process the tokenized credential. It could be immediate, but it could also be an asynchronous process.

rsolomakhin commented 8 years ago

Shouldn't it be the payment app that is controlling the experience at that point, not the mediator?

In step "5. Payment Response (tokenized)", the payment app has given control back to the mediator. The payment app should close at this point. Closing the payment app is useful if the transaction fails, for example, so the user can select a different payment app in the mediator and re-attempt the transaction.

rsolomakhin commented 8 years ago

We have no way of knowing how the payee will process the tokenized credential. It could be immediate, but it could also be an asynchronous process.

If the payee wants to dismiss the mediator UI, then the payee should call PaymentResponse.complete("") method. The empty string indicates that the payee can't tell for sure whether the transaction is complete, but the user can go on to other tasks now.

dlongley commented 8 years ago

As I recall, there may be some reason for a "complete" message because of Apple Pay... but I'll let someone more knowledgeable about that respond if that's the case.

My thoughts are:

Shouldn't the mediator just pass the payment response right through to merchant site and close? If the payment fails, the flow can't be easily recovered, right? Doesn't the merchant site have to start a new flow? If they don't have to start a new flow, doesn't the merchant site need to communicate something that passes through the mediator to the user to tell them what to do next?

It seems to me that the user experience be better if you don't have to see an error message in the mediator, close that, and then also see an error message at the merchant site directing you as to what to do next. It also seems better for control to simply go back to the merchant site so they can customize how to direct the user's next step. That way we can remove any need for designing something to allow the merchant site to communicate error information back to the mediator that the user can act on -- and specifying how the mediator is to present choices to the user based on that information. This also means there would be fewer decisions merchant sites need to make to figure out whether they should keep the mediator UI open based on the type of error that occurred.

On the other hand, the user experience in the case of a rejected card, for example, would be pretty frustrating. I would go through the checkout process, select my shipping address, etc., open a payment app, select a card to pay with -- and then the payment would fail and I'd have to start over. Ideally, I'd only have to choose another payment app and card again.

So, given that a design choice to integrate checkout choices like shipping address into the mediator has been made (as opposed to keeping them on the merchant site), it makes sense to have this added complexity.

rsolomakhin commented 8 years ago

If the payment fails, the flow can't be easily recovered, right?

Ah yes, you're right.

As I recall, there may be some reason for a "complete" message because of Apple Pay.

That is correct.

Shouldn't the mediator just pass the payment response right through to merchant site and close?

The way the API is defined today, the merchant website is in control of when the mediator closes (via complete(string) method). If the merchant chooses to close the mediator immediately, they are free to call complete("") before processing the transaction.

dlongley commented 8 years ago

The way the API is defined today, the merchant website is in control of when the mediator closes (via complete(string) method). If the merchant chooses to close the mediator immediately, they are free to call complete("") before processing the transaction.

This seems to be what we ought to always recommend that merchants do since the flow can't be recovered.

rsolomakhin commented 8 years ago

The way the API is defined today, the merchant website is in control of when the mediator closes (via complete(string) method). If the merchant chooses to close the mediator immediately, they are free to call complete("") before processing the transaction.

This seems to be what we ought to always recommend that merchants do since the flow can't be recovered.

You're correct that the mediator cannot recover if the merchant rejects the transaction. However, I would not want to recommend merchants to immediately call complete("") before processing the transaction. This forces merchants to show their own "Processing..." spinner, which is going to look different on different websites. These merchants would lose the advantage of a unified mediator UI, to which the user is accustomed.

dlongley commented 8 years ago

If the merchant has the guarantee that implementers of the API will provide that sort of activity UI then that makes sense for some use cases (i.e. there's no additional/useful information that can be shown to the user during processing other than a simple activity spinner).

rsolomakhin commented 8 years ago

That's how Chrome implements it. Not sure what other browsers do.

dlongley commented 8 years ago

That's how Chrome implements it. Not sure what other browsers do.

If that's not something that the merchant can rely on across implementations, they won't want to implement it that way (they'll do their own activity spinner).

ianbjacobs commented 3 years ago

This document has been deprecated, so closing this issue.