Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add failing scenarios for CVV verification of an existing card #644

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Add failing scenarios for CVV verification of an existing card #644

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
425adb9
Add failing scenarios for CVV verification of an existing card
jbrowning Jun 6, 2014
e41d780
Make it more explicit that this is a re-verification of CVV
jbrowning Jun 6, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 60 additions & 1 deletion features/cards.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,6 @@ Feature: Credit cards
}
"""


Scenario: Retrieve a card
Given I have tokenized a card
When I GET to /cards/:card_id giving the card_id
Expand Down Expand Up @@ -580,6 +579,66 @@ Feature: Credit cards
}
"""

@failing
Scenario: CVV re-verification matches
When I PUT to /cards/:card_id giving the card_id, with the body:
"""
{
"cards": [{
"cvv": "123"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the transmission is also going to fall into pci scope

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that could be a possible way to do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}]
}
"""

Then I should get a 200 OK status code
And the response is valid according to the "cards" schema
And the fields on this card match:
"""
{
"cvv_match": "yes"
}
"""

@failing
Scenario: CVV re-verification does not match
When I PUT to /cards/:card_id giving the card_id, with the body:
"""
{
"cards": [{
"cvv": "200"
}]
}
"""

Then I should get a 200 OK status code
And the response is valid according to the "cards" schema
And the fields on this card match:
"""
{
"cvv_match": "no"
}
"""

@failing
Scenario: CVV re-verification is unsupported
When I PUT to /cards/:card_id giving the card_id, with the body:
"""
{
"cards": [{
"cvv": "901"
}]
}
"""

Then I should get a 200 OK status code
And the response is valid according to the "cards" schema
And the fields on this card match:
"""
{
"cvv_match": "unsupported"
}
"""

Scenario: Adding card metadata
Given I have tokenized a card
When I make a PATCH request to the href "href" with the body:
Expand Down