Historically, this approach to data flows created the opportunity for nefarious users to intercept and rewrite payment messages (amounts in particular) and the relevant confirmatory messages. All can be solved with signatures and hashes but this vulnerability is a reason why redirect via the browser or other agent fell out of vogue. Nick -- Nick Telford-Reed e: nicktr@gmail.com m: +447538177619 On 3 Dec 2015 3:10 a.m., "Manu Sporny" <notifications@github.com> wrote: > It is not clear to me how an API instantiated on a merchant page will deal > with redirects to a payment provider site and still be able to provide a > return result. > > To be clear, this is also possible via URL-based callbacks, you can relay > messages using that mechanism, but it forces Web developers to initiate a > payment at one location and complete it at another location (which is done > today, but it's not as nice as just waiting for a promise to be fulfilled). > Note that this second approach is sort of what the HTTP API uses (because > that sort of programming paradigm is more common place in non-browser HTTP > clients): > > > http://web-payments.github.io/web-payments-http-api/#processing-a-payment-request > > — > Reply to this email directly or view it on GitHub > <https://github.com/w3c/webpayments/issues/16#issuecomment-161503004>. > --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/16#issuecomment-161542637Received on Thursday, 3 December 2015 07:45:31 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:12 UTC