Consider revising the design of complete()

[adrianhopebailie]

In TAG review @triblondon said:

paymentRequest.complete feels slightly weird, and I'm wondering why the merchant page does not instead receive an unresolved promise that it can resolve or reject. That would seem more aligned with the use of promises elsewhere.

[adrianhopebailie]

complete() was addressed in PR #161 but this specific issue was not dealt with. A proposal is required to address this and other comments made in the PR

[adamroach]

The existing design calls for three possible values here (success, failure and a third state representing "unknown"). That doesn't map well into the binary success/failure model that Promises provide, and the point of PR #163 was to expand from two choices into three.

While I agree that Promise would be a better choice if we could guarantee that the web page knows the success status, moving in this direction seems to reintroduce an already-solved problem. Perhaps we could include information in the resolution case to distinguish between "success" and "unknown"? It seems somewhat inelegant, but better than what we have now.

[dlongley]

We could resolve a promise with a status (success being one ... and this unknown or whatever else being other options) -- or reject it with an error.