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

Sure, from issue #19, here are the uses cases I identified;

1. Immediate Payment (my view is that this is the implied use cases for the API as it currently stands)

2. Payment on shipping of goods/provision of services (i.e. authorise now, but request funds when the goods are shipped - note many credit card Ts&Cs require this approach): [Ref: IG use-case 6.3.3]

3. Funds Hold (e.g. for a hotel room deposit, where you may pay by an alternative means later) [Ref: IG use-case 6.1.1: Hold Funds (currently this is not categorised into Phase 1, but I believe it should be - I think it is a more common use case than Refund, see number 7 below)]

4. Recurring Payment (subscription) with a specific schedule. [Ref: IG use-case 6.1.2: Subscription]

5. Registration (as above, but when the payment instrument is kept on file for later use) [no specific use case identified, but implied by IG use case 6.1.2 Registration-less]

6. Identification of a individual (i.e. not a payment) [Ref: IG use-cases in 6.2.3]

7. Refund (whilst we haven't discussed this in the WG to date, and I think we've implicitly assumed it to be out of scope) [Ref: IG use-case 6.4.3]

'identity' maps to item 6
'authoriseDeposit' maps to item 3
'authoriseDebitOnShipment' maps to item 2
'immediateDebit' maps to item 1
items 4 & 7 are not yet supported by the API
item 5, I see, needs another enumeration added, I suggest 'registerPaymentCredential' or similar.

I'm sure we can find better, more consistent descriptions, but hopefully this conveys the gist.

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