Re: [w3c/browser-payment-api] complete() should take a string argument not boolean (#17)

@jnormore said:

> Isn't Apple Pay considered a Payment App, just implemented by the browser? 

Yes

> This implies some mechanism for the user agent to pass the success value to the payment app, unless we consider those implemented by the user agent to be a special case because that communication mechanism is an implementation detail.

This is part of the conundrum we face with where we draw the line in terms of defining the integration between the user agent and payment app. We need to create a level-playing field for payment app publishers but also ensure we support the current status quo (a challenge when you consider that many of the browser vendors ALSO have a payment app).

The architecture we have proposed does attempt to address this by saying; from the perspective of the API there is only one exchange between the user agent and the payment app. That is when the user agent passes focus to the payment app and hands it a payment request. Once the response comes back from the payment app the channel is closed BUT for UI purposes the user agent may not have torn down the UI hosting the payment app (or taken focus back from the payment app), hence the need for a complete() call.

The complete() method call and various events that are raised are only exchanges between the website and the user agent. Perhaps there is an alternative way that ApplePay could acheive what's it aiming for here?

> I don't think the user agent has enough context to display that message properly on behalf of either the merchant or payment app. IMO the merchant should handle any success message (and even some critical failures, for example when there's no inventory) themselves, they have that context of how to follow up with the customer after purchase.

+1 - the merchant can provide the user with necessary feedback (as is done today). I think @mattsaxon  makes a fair point around the payment app wanting to know the outcome of the transaction but again I'd advocate for this being done outside the API as it doesn't need to impact on the UX. (Per #109)

> This brings up the non critical failures, such as a validation error, where the merchant doesn't want to reset the entire checkout experience for the customer (this would be a bad experience if I just entered by CC expiry wrong for example), they only want to bring them back to the last step to re-enter the invalid payment info and try again. I'm curious if this has come up with any discussions yet?

The hope is that by using this model (of data being exchanged between a payment app and the website) that validation errors all but disappear. I don't think we can support the idea of returning to the payment app in the context of an existing payment request.

I'd expect the merchant to call complete() to regain focus, notify the user that there was an error and call the API again with the same payment request (probably triggered by the user hitting a retry button or similar).

---
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/browser-payment-api/issues/17#issuecomment-204348937