Add failing scenarios for CVV verification of an existing card

[jbrowning]

Adds scenarios for the cvv portion of #11.

Address re-verification scenarios will be submitted via a separate PR.

[matthewfl]

I believe that the cvv is inside pci scope, which means that you can not redirect this number through your server (unless you are pci compliant). There needs to be some way of sending this through balanced.js but then reliable reporting the result to the server.

[jbrowning]

Yes I was wondering about that. I know the storage of the CVV is prohibited by PCI but I could not find any authoritative answer as to a CVV-only transmission.

[msherry]

That makes this operation tricky. The CVV would have to be submitted to Balanced by balanced.js, which performs unauthenticated operations, so it would be tricky to operate on a specific card resource. We'd need a way to perform the CVV submission from balanced.js, then attach that information (CVV token?) to an existing card and re-verify server-side.

[matthewfl]

the transmission is also going to fall into pci scope

[jbrowning]

Perhaps the solution would be to have a CvvVerification resource that can be created via balanced.js and then retrieved server-side to get the verification result.

[matthewfl]

that could be a possible way to do this.

[mahmoudimus]

@matthewfl A transmission of the CVV when the card is already tokenized is not in violation of PCI, however, I could see an auditor actually argue both ways here. So, my suggestion is that a generalized tokenization resource would work here.

[matthewfl]

right, but as this is written, it appears that the cvv is being passed through our customer servers, which would then fall under pci

[jbrowning]

This definitely feels like a gray area. For example, CVV + card token does not by itself give a bad guy enough information to actually charge a card. I could see this being a security concern if they were targeting a specific person/card though.

@mahmoudimus so are you suggesting that we go with submitting the cvv for verification via balanced.js with authenticated retrieval in the backend to get the result? In other words, an almost-identical approach as the existing payment instrument tokenization? If that's the case, then I'm happy to go back to the drawing board and continue the discussion in #11.

[jbrowning]

@matthewfl @msherry any update on this? Thanks!

[matthewfl]

@jbrowning you haven't really address the issues that we raised earlier

[jbrowning]

Well I believe we concluded that this approach may not be possible because we can't perform authenticated operations via balanced.js. If that is indeed the case, then we'll need to agree on a different approach, such as the CvvVerification resource that I suggested.

How should we proceed?

[matthewfl]

then you should write up a spec for a cvvverification resource, and then we can have a conversation about that, and possibly rewrite it again

[karthik1516]

I don't know how other people handle CVV validation. For example, hotels.com does a CVV verification when an existing card is used for booking. It will be really helpful for my marketplace, if you can come up with a solution. Until then, I will have to re-tokenize by getting all the CC information again.