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

The list of transaction types comes from an analysis of the existing types offered on a variety of existing payment gateway APIs. (Search for "Transaction Types" and see what you find. I took those that seemed appropriate and found simple terms that were a good aggregation and seemed easy to understand for a lay developer).

These types serve two purposes:
 1. To assist the user agent to display the line item amounts correctly considering internationalization and possibly hints (like an icon) that reflects the transaction type. 
 1. To assist the payment app in understanding how to process the payment.

_*NOTE:*_ The terminology "debit" and "credit" are appropriate payment terms and their use aligns with our resolution to follow ISO20022 terminology where appropriate

@zkoch  said: 

> We don't support refunds or credits, so I don't see the need to include those options. If this changes in the future, we can append those

Who is we in this context? Google or the WG? Surely the supported transaction types is determined by the payment service providers involved (all of whom appear to support credits/refunds based on my research). i.e. If the merchant supports credits/refunds and the payment app does to why prevent these transactions by restricting the API?

Obviously there is an implicit requirment that a merchant allowing an online refund will ensure that the payment methods they list in the request all support credits (the same applies for all of the other transaction types)

> I think it's unnecessary and too complicated to have the type specified per line item. It should be across the entire transaction.

The per line item type allows you to include credit line items like discounts which should be displayed differently to, for example, a sub-total which is a debit. Remember that CurrencyAmount is supposed to be an unsigned number (per our resolution https://github.com/w3c/webpayments/issues/57) - see PR to correct it: https://github.com/w3c/browser-payment-api/pull/101

> I don't full understand the difference between "capture" and "debit"

Based on what I read on other APIs "capture" is the process of capturing the payment details for future use whereas debit is an immediate payment. I'm not married to "capture" as a type but I think we should have "debit" and "credit".

> There should be a default set across the entire transaction, which I would imagine is either "capture" or "debit"

The default is "debit" but for some reason when I put that in the WebIDL it wouldn't compile properly so it's mentioned in the spec text.

@mattsaxon, I think we should support all those use cases (including recurring payment and refunds) although I'm unclear on "identify" and why this is in scope?

All that is required for the API to support these use cases is to list the transaction type in this enumeration. Whether the transaction is supported by the payee or the payer payment app is dependent on the payment method that is used. I see no reason for us to restrict this intentionally.

In terms of the actual terms I am wary of us being too card-centric here which is why I have used more generic terms like "debit", "credit", and "authorization". I think ISO20022 verbs are the right things to use because these encompass a more full breadth of payment flows.

That said, I'd invite some input from @mountielee on whether we need explicit terms for escrow or any other payment types we have missed here.

Really, this list should be an aggregate, simplified, list of the transaction types supported by the various payment service providers that will publish payment apps and process payments for payees. As mentioned in the included issue marker we might want to make this list extensible.

---
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-204302000