Allow a marketplace to validate the cvv2 or address after creating a card token

[matin]

Balanced verifies a card with the networks and issuing banks when a card is tokenized. The cards endpoint only supports a one-time POST.

There have been requests to allow a marketplace to validate the cvv2 on an existing card. The proposed use case is to request cvv2 on subsequent transactions (without asking for the card number again) to reduce risk.

Proposed interaction: PUT on cards resource with the security_code reverifies the card

UPDATE (5/29/13): include AVS as part of the proposal.

[joeyAghion]

+1

[dsog]

+1

[matin]

This is possible for us to provide, but it needs to be prioritized. We will update once there is a timeline.

[stefanhenze]

+1

[jaGarcia]

+1

[blim8183]

+1 we're trying to add postal codes to cards that were tokenized without one

[jrus]

@matin can we also include adding the name after tokenization to this issue?

[jkwade]

I had a few conversations yesterday with some dual-factor authentication vendors. It seems re-verifying CVV would serve much the same purpose.

[MindaugasJ]

+1

[MindaugasJ]

It is really big need to have CVV rechecked on card update. As storing the card allows anyone with access to account to do payments.

[quellhorst]

:+1:

[jkwade]

Throwing my +1 in here too. I think this could be a great security measure for always logged in marketplaces that sell high-value items.

On Saturday, October 12, 2013, MJ wrote:

:+1

On Sat, Oct 12, 2013 at 12:09 AM, Dan Quellhorst <notifications@github.com <javascript:_e({}, 'cvml', 'notifications@github.com');>>wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub< https://github.com/balanced/balanced-api/issues/11#issuecomment-26174169> .

Mindaugas Jankauskas +37061030143

— Reply to this email directly or view it on GitHubhttps://github.com/balanced/balanced-api/issues/11#issuecomment-26193887 .

co-founder & growth, Balanced http://balancedpayments.com/ Join the Balanced Community: Facebookhttps://www.facebook.com/balancedpayments | Twitter https://twitter.com/balanced | Githubhttps://github.com/balanced/ Balanced in the Press: Forbeshttp://www.forbes.com/sites/evankirkpatrick/2013/04/02/how-the-balanced-co-founders-went-from-meeting-on-craigslist-to-raising-millions-from-famous-investors/ | Fast Companyhttp://www.fastcolabs.com/3008944/open-company/why-i-made-my-payments-startup-an-open-company | Techcrunchhttp://techcrunch.com/2013/04/02/balanced-andreessen-horowitz-collabfund/

[jbrowning]

@matin as this issue is almost 2 years old could you please provide an update on its progress/prioritization?

[mahmoudimus]

@jbrowning I believe the new revision of the API has solved this problem. Let me double check.

[matthewfl]

@jbrowning we currently have cvv and address checking on the initial tokenization as you likely already know, however we are currently missing this feature for cards that are already tokenized. Would you be up for submitting a failing test that is similar to: https://github.com/balanced/balanced-api/blob/master/features/cards.feature#L496-L516

[jbrowning]

@mahmoudimus @matthewfl thanks for the update.

Sure thing. I'll get working on that failing test tonight.

[CharlesBergmeier]

Hey guys - just wanted to check on the status of this feature request, and add my :+1: for it as well.

Implementing a feature like this has several benefits:

• Mitigates the risk of a fraudster gaining access to a user's account containing active credit card(s)
• Helps fight chargebacks by requesting a buyer re-enter AVS and/or CVV information when making a purchase.

Perhaps I can suggest a slightly different implementation, that could make this feature accessible sooner (and would be more closely aligned with your inevitable back-end implementation). What if there was an extension to the POST functionality, that allowed you to create a new card from an existing card uri + user provided cv2? Then the client side could tokenize a new card via those 2 inputs, and the card could then be investigated by the server to see if the cv2 (and other checks) validated successfully.

If that implementation was successful, the pattern could be extended to include other fields too. Like maybe they want to create a new card that is merely their old card updated with a new billing address? Then just POST would take card uri + cv2 + billing address data. And so on.

The advantage to POST over PUT as well means the checks are not destructive/persisted. If the cv2 code doesn't match, then nothing has been changed about the original card on file. And then I can make decisions on my end on whether that means deleting the old card, saving the new bad card, or some other action.

[mjallday]

@CharlesBergmeier i believe the issue is that PCI compliance requires the CVV to not be passed through your server unless you are fully PCI compliant. Having said that, we have, in the past, had a clone method on cards and that could be part of the solution.

What would ideally happen is that balanced.js is used to send the CVV directly to the Balanced API from your user's browser. It's less an issue of API semantics as opposed to finding a good way to send the data securely.

Maybe we can do something like balanced.card.verify(card_href, cvv); in balanced.js. The issue then becomes that since this is an unauthenticated operation (you do not provide API credentials to balanced.js since it's not secure) we do not want to allow this operation to make a call to the bank to verify, so this would then need to be matched to a authenticated server side call to complete the verification.

Here's a quick off-the-cuff example of how maybe this could work in the browser:

var verification = balanced.card.verify(card_href, cvv, address_data);
$.post('/your/backend', {card_verification_href: verification.href});

and then on your server

import balanced
balanced.configure('ak-test-123123123')
verification_href = request.POST['card_verification_href']
try:
    balanced.CardVerification.find(verification_href).verify()
except balanced.exc.CardNotVerified as ex:
    print ex.reason

This could be implemented with clone in place of verify but I'm then we'd need to do something to enforce cvv or address being accepted since it feels to me like if you allowed someone to clone a card they could provide another card's href.

@balanced/spec-ialz any thoughts on this? it could help cut fraud so i think it's worth exploring.