- From: Marcos Cáceres <notifications@github.com>
- Date: Wed, 23 Nov 2016 23:39:11 -0800
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/issues/330@github.com>
This is a follow on from #326... the ability to use this API with HTML forms seems limited, which strikes me as quite odd given that this API just collects form data. In particular, web applications that are loaded on UAs that don't support this API will need to use HTML forms. Additionally, `PaymentResponse` needs to be validated in the same way that one would validate a HTML Form. And, in most cases, `PaymentResponse`, needs to be POSTed by the developer as `FormData` to a server for verification. Thus, it feels deficient that I can't easily do the following (given we have extensive form validation and form-related primitives in the platform): ``` // If the UA doesn't support the API, then use this flow: HTML form -> user fills out data -> form.checkValidity() -> form.submit(); // If the UA does support the API, then the flow is: (hidden) form -> PayRequest -> PayResponse -> form -> form.checkValidity() -> form.submit(); ``` Going from a `PaymentResponse` to populating a form is not overly traumatic. But could be made much more coherent. Additionally, reusing more of the existing form infrastructure could significantly reduce the API surface. -- 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
Received on Thursday, 24 November 2016 07:39:46 UTC