Sure. Or 2FA or whatever. There are a lot of ways to help "secure" the customer-side of the transaction. I would also note that all of the messages in this API are already encrypted over the wire. So what we are talking about is the content of data structures as they move among various layers of the architecture. I think the risk of MitM is pretty low... On the other hand, if I were using a third party payment app on a public computer at a library, I wouldn't want the PAN coming out of my payment app visible at all to the user agent. My solution to that is to not use computers at libraries - but not everyone has that luxury I imagine. On Mon, Jul 11, 2016 at 12:15 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2016-07-11 17:24, Erik Anderson wrote: > >> How is the current Basic Card mechanism any less secure than what is >>> done today using web forms to capture card details? >>> >> >> Adrian, time.... Time changes everything, Chip-n-pin is causing fraud to >> move away from the Merchant terminal to online. Laws are changing quickly >> to adjust. >> >> > The quick route to on-line security comparable to Chip-n-pin, is > off-loading client-side payment operations to a locally installed native > "App" like Apple and Google do. It is essentially the same thing as a > payment terminal in the physical world. > > Some people claim that these solutions even surpass Chip-n-pin > security-wise! > > Anders > > > -- Shane McCarron Projects Manager, Spec-Ops
Received on Monday, 11 July 2016 17:32:35 UTC