- From: Zach Koch <notifications@github.com>
- Date: Wed, 07 Dec 2016 20:09:03 -0800
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/issues/330/265648225@github.com>
Marcos, it seems as if you're getting caught up on the idea of "web sites currently use forms to collect credit cards, so we should optimize for that." This is what requestAutocomplete was, and we decided that was insufficient for our needs. Chrome was also the only browser to implement, even after a number of years. A few quick answers to your questions: > Existing web store fronts that are already using forms. Yep, and they will continue to have to for the foreseeable future. At least, until we can rid the world of basic card payments. :) This itself is not a strong case for making forms the backbone of every payment response, the responses of which can be *very* varied and quite complex. > Validation of the Payment Response (where 1 already has form validation - via form.checkValidity()) I'm no expert here, but what does a validity check for a proprietary payment response look like? What about for a Stripe token? Or an Apple Pay response? Or a SEPA credit transfer? It seems to me that validation checks for anything other than basic card are not feasible on the client. In addition to that, what happens if client-side validation fails? How does a user fix a network token? > The site expects the form to be submit()ted somewhere. Perhaps. We can all agree the payment data ultimately needs to be sent somewhere, but that somewhere is quite varied. It could be Braintree's [client-side JavaScript API](https://developers.braintreepayments.com/reference/client-reference/javascript/v2/credit-cards), where you don't submit() you client.tokenizeCard(), for example. But these issues aside for the moment, I think the larger point is that the time for such a large change has passed. If this is a path the WG wants to go down, we should consider how we can add this later in a backwards compatible way. This does seem reasonable, though: > If we do choose to keep the current complex object hierarchy, we should perhaps consider instead adding .json() and .formData() methods instead? Would this work by allowing a user to do something like, `paymentResponse.toFormData()` or similar? -- 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-265648225
Received on Thursday, 8 December 2016 04:09:38 UTC