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

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

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