Re: [w3c/browser-payment-api] Should the API handle pre-auth, recurring payments, and similar scenarios (#19)

Can we use this thread to define the specific set of transaction types we want to include. My PR at https://github.com/w3c/browser-payment-api/pull/111 proposed a list :

 * debit : A standard payment/debit against the payer's account.
 * credit: A refund/credit against the payer's account.
 * authorization: A request to authorize a payment that may be settled between the payer and payee at some time in the future. The specifics of an authorization will depend on the payment method that is used to process the payment.
 * capture: A request to capture the details of the payer (and possibly the payment itself) for future use.
 * repeat-debit: A request to peform repeated future debits against the payer's account. This may be for any recurring payment such as a subscription. The details of the recurring payment should be handled by the payment method.
 * repeat-credit: A request to peform repeated future credits against the payer's account. This may be for any recurring credit such as a wage payment or proceeds of a sale. The details of the recurring payment should be handled by the payment method.

@mattsaxon has proposed a different list based on the use cases he identified above:

'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.

@ianbjacobs I would consider multi-tender a different requirement that justifies a different issue.

---
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/issues/19#issuecomment-204327660