Re: [w3c/browser-payment-api] Add PaymentItem type to deal with transaction types (#111)

> Matt's suggestions make more sense to me if the intention is to allow the payment app to give a better user experience. That multiple user experiences map onto a single underlying transaction implementation type doesn't mean that those terms are the most useful ones in this case. 

This sounds too much like we are dictating to the payment app what the user experience should be.

The intent here is for the payment app to correctly reflect to the user what is being requested. i.e. Is this just an authorization or will you be charged when you authorize this transaction? Am I signing up for a subscription service or a one-off payment? Is this payment in some way tied to the delivery of goods so I know the payee won't be settled until after the goods have been shipped?

Perhaps this can all be conveyed in the payment method data in the request but it seems sensible to have a standardized list that is agnostic to avoid this becoming very fragmented.

I want to emphasize again that we shouldn't make this list too card-centric. If our transaction types are not generic then the choice of transaction type by the merchant immediately imposes a restriction on the payment methods they'll offer which is counter to our goal of making it easy to introduce new payment methods on the Web.

My suggestion is that we merge this with the addition of an issue marker pointing to a new thread discussing the appropriate set of transaction types.

---
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/pull/111#issuecomment-204324808