Re: [w3c/webpayments] Letting the payment app decide between HTTP and Javascript communication (#130)

> > So, if we're going down the POST path, I would suggest we contemplate using POST for all interactions, and describe how to use service workers to process such requests locally.
> 
> I agree with this and only propose the JavaScript option as an addition. It never hurts to give developers choices.
> 
> In that respect, I think #131 is a more extreme change than we need. I don't think we should take out the existing behaviour but rather add other behaviour if the app chooses to use Javascript.

Are you proposing then, to still POST the serialized PaymentRequest to payment apps who only want to deal with javascript? Will these payment apps then ignore the POST'ed payment request and use `navigator.payments.getRequest()` instead? I feel that this is very inelegant, and that there isn't that much benefit to be had from doing it this way.

I do think there is a significant amount of payment apps that will strongly prefer javascript over POST for the simple reason that POST requires server-side scripting to process, whereas javascript can be done entirely client-side, which makes it possible for the payment app html to be served out as an entirely static page. This can be a great advantage for major payment providers, whose payment apps have to process large amounts of payments.

---
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/webpayments/issues/130#issuecomment-220325026