According to the Stripe FAQ, they are PCI-compliant. Also, in their API documentation, one of the parameters to create a new card is the CVC (although, granted, it is optional). So, I assume they store the CVC for subsequent credit card transactions. But the PCI DSS strictly forbids you to store CVV, CVC etc.

So how can they be PCI-compliant?

  • 7
    I think your assumption is incorrect. I think it's far more likely that they use it for an initial verification, and do not store it. If they've proven that you know it the first time, there's not even any reason to store it. Quite the opposite in fact. If they ever felt the need to reverify, they would want the user to provide it again, not pull it from their own system.
    – Xander
    Aug 29, 2013 at 18:05
  • Ok, but Stripe is just a payment gateway. They still need to send the CVV to their acquirer when making a transaction. And ultimately, it's not Stripe who decides whether the user knows or does not know the CVV; it's the credit card issuer, right? What am I missing? Oct 1, 2013 at 16:23
  • 1
    Even so, they still shouldn't need to send it for every transaction. They're going to send it initially, and the processor will then send them a token back that they can use for future transactions, just as your app would get if you were dealing with the payment processor directly. So all Stripe needs to do is forward the card information to the processor to confirm validity, and then they need to store the token they get back, but not the raw card data. Does that make any more sense?
    – Xander
    Oct 1, 2013 at 16:38
  • Newer methods use tokenization tied to your website. The credit card details get validated and stored on the processor's PCI compliant servers (less CVV) and a token tied to the web merchant's server is all that's stored on the website. Jan 6, 2015 at 4:17

1 Answer 1


(Disclosure, I work for Braintree, a competitor to Stripe)

At Braintree we also allow the CVV code to be passed in our API. You are correct that the PCI-DSS explicitly forbids non-issuers from storing the CVV. You are allowed to hold the code temporarily while waiting for the charge to be authorized. This is stated in PCI-DSS Requirement 3.2 (additional formatting is my own):

3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

It goes on to define sensitive data as including the CVV:

Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.

What this means is that service providers and merchants are allowed to take the CVV value, they just cannot keep it stored in their database for future use.

In the API you are looking at, the creation of a new vaulted credit card, the CVV is used to run a verification on the card. A verification is a type of authorization that ensures the account is active and able to be charged before we store it. After the verification is returned we discard the CVV. This allows us to give merchants a warning that the card their customer just added will fail the next time they go to use it.


You must log in to answer this question.

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