2

I know there's a question that's been already asked but it's a decade old so wanted to get an up to date answer...

It's mentioned quite often that the CVV number should never be stored, but this must be the case for companies where frictionless payment is offered. How would a company like Uber do this and uphold PCI compliance?

Would it be possible to do this using the keystores for IOS/Android and still have PCI compliance?

Improve this question

3 Answers 3

Reset to default
1

The answer is that they don't store credit card details at all. They store credit card payment data using tokenization. See e.g. https://squareup.com/us/en/townsquare/what-does-tokenization-actually-mean for a primer.

Improve this answer
0
4

To add to the other comments, CVV2 / CVC2 is not required for recurring / account-on-file transactions. The first transaction made with the merchant generally does need the CVC2 or in the EU secure customer authentication. For subsequent transactions there is a special flag on the transaction that is for account on file and the issuer will authorise and pay without CVV2.

Some larger merchants will also 'trade' the PAN for an EMV token provided by the card issuer (usually Mastercard or Visa on behalf of the issuer) and then will store just the EMV token which can also be used for recurring payments without the CVV2 and has the advantage that it doesn't need to be protected by the PCI DSS requirements.

To answer your second question, you can't store PAN and CVV2 in a consumer application - although the consumer device is not in your PCI DSS scope, your app is, and so you would be breaking the "don't store sensitive authentication data after auth" rule. It's also not a great way of doing it. If you are going straight from your app to the acquirer for auth (ie bypassing your own servers) the it is better for your app to request a token from the acquirer and then store the token in the keystore as previous commenters have alluded to. Otherwise store the token in your server environment and match it up to the app user.

Improve this answer
4
  • Thanks very much for this. Just to quickly summarise then: app user adds card data, we send this from app to the payment processor who return a token if successful. This token can be sent securely to the server and stored with the relevant user id. Further payments will then be processed using this token until removed by the user or upon expiration. With this, no information other than the tokenised card details will be saved.
    – pma07pg
    Commented Apr 22, 2022 at 12:30
  • 1
    That's right. The great advantage of this is that your servers do not store, process or transmit cardholder data so reducing your PCI DSS scope. This document from the PCI SSC is quite old but you may find it useful. pcisecuritystandards.org/documents/…
    – withoutfire
    Commented Apr 23, 2022 at 13:27
  • @withoutfire Presumably (I hope!), the token is tied to the merchant it was issued to in some way, so that leaked tokens cannot be used by an attacker in the way leaked card-numbers could?
    – TripeHound
    Commented Apr 28, 2022 at 21:49
  • Yes. Acquirer/processor tokens are tied to the merchant, otherwise they become a general payment instrument. However, even if usable at multiple merchants they are tied to the acquirer/processor that issued them, so they could only be able to be used at another merchant using the same acquirer. It is wholly acquirer risk in this case and if this was the case, that stolen tokens were used for fraud, the card brands would hold the acquirer liable. EMV/issuer tokens are tied to the merchant ID.
    – withoutfire
    Commented Apr 30, 2022 at 5:50
1

For merchants that do automated/recurring billing - most payment gateways offer a way for merchants to store credit card information on the gateway's servers in a tokenized fashion, so that merchant can charge customers' credit cards without the need for the customer to provide their card information for each charge.

For more info, see:

https://www.authorize.net/resources/find-a-partner/certified-solutions/authorizenet-cim---magemart.html

https://www.authorize.net/en-us/resources/our-features/recurring-payments.html

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .