Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76)

It occurred to me that it might be useful to tie this (and some other issues) back to our use cases at https://www.w3.org/TR/web-payments-use-cases/.  On the other hand, there are no use cases in the document that explicitly call out for this feature IMHO.  Moreover, any merchant site should have gathered coupon, loyalty, and shipping options before they call paymentRequest anyway.  If that is not the case (or the customer has some late breaking information), I would just abort the paymentRequest call and re-issue it with the updated information if it were my site.  That would work better with issue #79 anyway.

Having said all of that, here are a handful of use cases that I think are related to this issue:

6.1 (Point of Sale Kiosk) - the various interactions would result in things like recalculating prices as coupons are applied.

6.1.2 (One-time Payment) - if there were an option to upgrade to a recurring purchase for a discount that might result in a recalculation.

6.1.3 (all of them) - coupons, credits, cards - these things might get applied during the wallet action, and the wallet would need to iterate with the merchant server.

6.2.2 (manual selection of payment instrument) - selecting different payment instruments might result in pricing changes; use your debit card, get a discount; use your store-provided card, get a discount; use american express, pay a premium.

6.3.2 (funds verification) - I could see an iterative cycle where the wallet identifies funds available in multiple payment accounts, the payer wants to use several instruments, and then there are varying
discounts or fees associated with the multiple cards.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/76#issuecomment-181050769