Re: [webpayments] How are cloud-based payment instruments supported? (#16)

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-161542637