How come Appstore gets to store CVV2? [closed] - app-store

Question

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How Appstore gets to skit round this restriction? Can CVV2 details be kept locally on an iOS device and still be in PCI compliance? Encrypt the CVV2 details locally, and only user has the key? While the rest of the credit card details like PAN are stored on server side?

Answer 1

SHORT ANSWER:
Your issuing bank doesn't require security code validation with every transaction.
LONG ANSWER:
Card security codes and magnetic stripe data are not permitted to be stored by PCI DSS. Furthermore, VISA (and possibly other networks) strictly forbid their storage:
http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
Merchants storing this data can be hammered with hefty fines and dropped by processors. This happened to a client of mine.
Apple's e-commerce system asks for the security code when an account is created or whenever a new device accesses an existing account. In both instances, their platform initiates a zero-dollar transaction with the processing network to verify the customers' identity (username + password + security code):
https://discussions.apple.com/thread/2594628?start=0&tstart=0
Some issuing banks require security codes to be used with each transaction. In those cases, the iTunes store will prompt you for the code.
xixonia is correct that personal data is tokenized within Apple's infrastructure. Most of their servers never touch secure data, as all credentials and financial data is passed encrypted to an inner network of highly protected and monitored systems.
In addition, large retailers like Apple and Amazon use third-party fraud detection and prevention technologies that look for patterns of abuse.
"It is permissible for issuers and companies that support issuing
services to store sensitive authentication data if there is a business
justification and the data is stored securely"
Easier purchasing and subsequent transactions are NOT business justification.
A pertinent use case would be batch transactions. During purchase the card is authorized to confirm the card is active and the funds are available. The issuing bank typically encumbers, but does not withdraw, the transaction amount from the cardholder's account. During a subsequent capture transaction, the merchant settles with the processor and the funds are transferred. This might happen because:
The issuing bank requires it (e.g., voice authorization).
The payment network requires it (e.g., American Express used to).
The merchant does not know the full transaction amount (e.g., restaurant tip).
The merchant does not have persistent connection to the payment network (e.g., mobile operator).
Going this route triggers MUCH higher scrutiny under PCI DSS. Merchants who use third party checkout systems like Google Checkout and PayPal get minimal treatment (SAQ A). Merchants who store ANY cardholder data have the heavy burden of SAQ D.
The compensating controls for holding security codes & magnetic stripe data are even more strict:
Data must be stored using best practices (randomized salt + strong encryption cipher + restricted keys + mandatory access controls + audited access).
Data must be automatically removed after a set grace period (typically a day or two).
Data must be securely overwritten and on a medium that allows it (most solid state drives' wear leveling mechanisms prevent this).