[webpayments] How can the API support enrollment (future payment) use cases? (#65)

Migrated from https://github.com/WICG/paymentrequest/issues/43

@ianbjacobs:

> Here is a use case that should be supported:
>
> * Service asks user at enrollment to register payment details for future use
> * API is used to retrieve those details, but no payment should actually take place.
>
> Some payment apps might support this (e.g., raw credit card information) while others might not
> (e.g., those that return 1-time tokens).
>
> What (if anything) does the API need to say to help readers recognize that it supports this
> enrollment use case?
>
> For example, suppose the preferred way to use the API for enrollment to specify amount=0.
> The spec should say something to that effect and, for example, ensure that the definition of
> amount supports that value.
>
> Or, there might be other ways the API could support the enrollment use case. I look forward to
> your thoughts.

@adrianba:

> There may be many occasions where a site wants to request a payment method but not to make a  charge. For example, it is common to provide a credit card number to book a car rental or to make a hotel reservation but the payment is made later, in person, and potentially with a different payment method. The merchant may charge the original payment method under some circumstances (for example no show at the hotel).

> This seems very payment method specific. Perhaps we need to explore the "amount=0" use case?

@mattsaxon:

> There are 2 sub uses cases to consider here;
>
> 1. An identification validation, amount=0 might be a reasonable approach here
> 1. A deposit/reserve, e.g. a hotel deposit, a common way of doing this to authorise an actual amount, but not make the charge unless something happens, this is known as an "authorisation" without a "capture", effectively these are two seperate transactions when can be bundled as a "sale". The flows we have documented so far don't differentiate these as the distinction occurs between the merchant and the merchant PSP, not between the shopper and the merchant. However it might be prudent to have a distinction in the target model so the user is aware what they are signing up to.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/65