Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330)

@zkoch, wrote: 
> I think I'm a bit confused by what "form data" means in this context. Does anything that can go into a JSON object constitute "form data"?

Sorry for not being clear, form data means this API: https://xhr.spec.whatwg.org/#formdata

> I don't think it's valid to compare this with "UAs that don't support this API" and their need to fall back to forms. 

Consider, Firefox will support this on Desktop, but we don't have any plans right now to support this on mobile... let's say, for arguments sake we don't ship on mobile until 2019 or later. I don't know what Chrome's plans are to support this on Desktop - but I imagine your desktop users will need a fallback too.

>From that perspective, it's totally valid to say that a UA won't support this API, as I know for a fact that we don't plan to ship this on mobile.  

> By falling back to forms, they're limiting the payment methods that are available. 

Yes, which is fine. It's what you want, really because at the very least one can support "basic card". Or just manual form input. 

>  For example, native-only forms of payment (e.g. Android Pay, Samsung Pay, etc) wouldn't be available. 

They won't be available on desktop anyway (at least, not yet). We will be lucky if we even get ApplePay on Mac in non-Apple browsers. Or we will be dependent on plugins. 

There are millions of people who will still need to pay the old fashion way on Desktop - but they too should have a great experience.  

> Put another way, there is no "pure form" equivalent of these forms of payment. As we get into more complicated forms of payment, this will continue to hold true.

I haven't seen any evidence of this yet - because at the end of the day, the payment response is either a token+some name/value pairs or the details of a credit card (both of which require the web app to verify those by POSTing that form data somewhere). 

I'm probably missing something tho. Can you help me understand where it gets more complicated than the above?    

=== 

@adrianhopebailie, wrote: 
> I am with @zkoch on this. I'm not sure I see the use case here beyond card payments.

A lot of people will continue to pay with cards. Cards are not going away. Their usage may actually increase (specially with dynamically-generated, time-bombed, exact value cards). For example: https://twitter.com/producthunt/status/802897292390866945  

> I'd expect that for websites that are posting the PaymentResponse to a server they'll simply POST the JSON in the body of a new request. I think this issue is implying that POSTing application/json is less desirable than POSTing application/x-www-form-urlencoded data?

This has limited relationship to how it's actually POSTed - and it's not about giving preference to one format over another. `FormData` is just a representation of the collection of the data as it relates to a form. That data can then be transformed to JSON or whatever.  

Thus, FormData is a primitive to represent the data. However, we would need to find a way to transform FormData into JSON by working with @annevk and friends from HTML.  



-- 
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/330#issuecomment-264365051