This issue comes from WICG/paymentrequest#43 and discussion at the F2F.

Should the API handle occasions when a site wants to request a payment method but not actually make a charge immediately. These may include identification validation, pre-auth for a deposit, pre-auth for a later payment, making recurring payments, and more.

I suggest the following use cases are investigated;

Many of these have been documented by the IG here https://www.w3.org/TR/web-payments-use-cases/#use-cases-1 and most are defined as being in Roadmap phase 1.

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]

It is my view that the distinctions between these should be clearly visible in the native user-agent dialogue 'pop-up'. Please see issue 60 where the display of the payment obligation is discussed also w3c/webpayments#60

Add to this list "multi-tender" payments, that is: should the API support paying the amount with N > 1 payment instruments?

Wouldn't 2 be under 1 but basically a financial implementation detail that's irrelevant to us?

Just an aside :

We're adding support for (anonymous of course) refunds, but not these others. In my view, refunds are actually fundamental to a transaction system, as nobody wants to send the money back through another channel, while most other features are interactions with the wider legal system, or somewhat orthogonal.

A funds hold for example is not exactly a capability that a true micro-transaction system can posses because it assumes payment provider can spend human time to negotiate between the customer and the merchant, which increases their fees.

@burdges, my view is that this comes down to what people are agreeing to when they hit "Authorise", at the moment, this is simply a proceed button, I believe it should be the point at which a contract is struck, aka a payment obligation in ISO20022. This 'agreement' should be signed such that in the event of dispute later it is clear what was agreed to and by whom.

To do this, the agreement needs passing into the API so it can be displayed to the user and so this can be part of the data that is signed.

I have referenced the need for signatures in issue #31 and also w3c/webpayments#60

Issue #52 was subsumed into this one. This one seems also to cover quite a few other things (the "and similar scenarios" in the title is rather an invitation to that and indeed the first comment starts a list.)

Should this be broken out into specific issues for the different use-cases ?

@mwatson2 +1 to split the issue into multiple issues, at least one each for:

1. One-time pre-authorization (where a hold for a specific amount of funds are placed once - reserving a room at a hotel or pre-auth'ing at a gas pump).
2. Subscription (where payments that occur at a regular interval and for a regular amount are requested - Netflix subscription).
3. On-demand pre-authorization (where payments that occur at an irregular interval for an unknown amount (but up to a certain limit) - in-game purchases, Play store purchases, etc.).

... aaand, I'm just now seeing that @mattsaxon already covered many of these in his comment above. I haven't yet tried to merge his list with my list above, so leaving the comments here for the time being.

Can we use this thread to define the specific set of transaction types we want to include. My PR at #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.

I think we should get this parameter in the appropriate place in the API first and get a candidate list in the spec, there will then be more context to have this discussion.

These are necessarily somewhat specific to the payment app/method. I'd expect a hotel might ask for a debit against one credit card type, or a authorization against another card type, based upon those card types fee structures. And systems like BitCoin have an entirely different world for this stuff.

I posted some thoughts on recurring payments on #111 (comment) and would like to add a vote for the importance of considering recurring payment use cases. I work for the Financial Times, and our business model is built on weekly or monthly recurring payments, mostly charged to credit cards for B2C customers.

As I have commented on the (now closed PR #111) I think this is a mistake.

I think transaction types are tightly coupled to payment methods and so we should not define them in the core API but look at the different types for the payment method specs we will publish and define them as request parameters in there.

The primary driver for standardizing these is to ensure that users are agreeing to something they understand. I don't believe that the user agent will take responsibility for this, it will be the job of the payment app to prompt the user to accept the payment terms and in so doing be clear about the obligation.

TL;DR: No, the API should not explicitly support these transaction types other than to not attempt to impose restrictions on fields like amount which may have a value of zero. Semantics about the type of transaction should be put in the payment method data.

We should rather focus on the real user requirement which is defined better in #113