notifying the payment app when a payment is complete

[halindrome]

The current complete() method does not (seem to) provide a channel through which the Payment App could be notified of the status of the transaction. We envision a Payment App that is part of a user's overall payments / transaction management system, and it would be good if that App could know that a request was accepted by the merchant and keep track of it.

I expect that the best way to do this would be by raising an event (paymentAccepted?) that a Payment App could listen for.

If people are open to this, I am happy to draft a PR.

[rsolomakhin]

Can we get feedback from payment apps in the group about this feature? (Samsung Pay, AliPay, etc)

[adrianhopebailie]

I expect that the best way to do this would be by raising an event (paymentAccepted?) that a Payment App could listen for.

Sounds like a requirement for the payment apps spec (not payment request spec)

[burdges]

Interestingly, we do not do this per se. A Taler wallet does know if the merchant has received all the coins it allocated to a particular transaction, but if the merchant tries again, like maybe because the user reloads the fulfillment page and the merchant did their checking oddly, then our wallet will send back exactly the same coins. We kinda interpreted "RESTful" in both directions when appropriate.

[adrianba]

The spec used to say this. The WG decided that it shouldn't and this step was removed. See #129/#161.

[adrianhopebailie]

@adrianba is right. We decided to keep this simple and refine it as the overall design changed.
See https://www.w3.org/2016/04/28-wpwg-minutes.html#item03

I propose (per @rsolomakhin) that we understand the requirements from payment app providers before we change anything in paymentRequest.

Is there a desire for the the website to be able to send payment method specific data in this call? (i.e. More than just success/fail)

[halindrome]

@adrianhopebailie I don't think that there is any need for more data in the complete call beyond that - the protocol / messaging would be sufficiently robust for me if there were just an event that would let the app know the payment actually worked.

[adrianhopebailie]

@halindrome in that case we need to log this requirement against the payment apps API spec.

Closing this issue as out of scope.

[halindrome]

Note that I disagree this is out of scope. The payment app spec should not be placing requirements on this spec that would create normative changes to the API. Throwing an event seems like a really easy way to ensure that anyone who cares can know that a transaction completed. But yes, there would need to be information in the event data to let the listener know which thing completed. The transaction reference that I proposed in issue #287 would be really good for this.

[adrianhopebailie]

Note that I disagree this is out of scope. The payment app spec should not be placing requirements on this spec that would create normative changes to the API. Throwing an event seems like a really easy way to ensure that anyone who cares can know that a transaction completed.

As I understand it, the event is caught by the payment app right? Therefor that event needs to be defined in the payment apps spec.

In that section of the Payment Apps spec it would refer to the appropriate point in the complete() algorithm definition of the this spec [1] when the browser MAY/SHOULD/MUST emit an event to the payment app.

[1] https://w3c.github.io/browser-payment-api/#complete

[halindrome]

Well, it would be caught by whatever wanted to catch it; including the payment app. I appreciate that the payment app could spec it, but I don't understand why it would want to spec it. But I am willing to bow to your wisdom. Do I need to raise an issue over there?

[adrianhopebailie]

Well, it would be caught by whatever wanted to catch it; including the payment app.

The PR API is an interface between the merchant website and browser so I don't know how an event defined here could be handled by the payment app, that's my point.

The web-based payment app (a ServiceWorker) is running in a different context and is interfacing with the browser through a different API.

I agree we should have this event I just think it should be defined in the payment apps spec.

I would suggest that, in addition to the paymentrequest event [1] we define a paymentcomplete event that the browser emits to the serviceworker to notify it that it is closing down the UI. This could allow the payment app some time to notify the user of the result before the browser shuts down the UI?

[1] https://w3c.github.io/webpayments-payment-apps-api/#the-paymentrequest-event