13

I need to validate and store credit card information (name, card number, expiration date, CVC) for retrieval at a later date. Once retrieved, the data will be used for manual processing on a separate system.

I have been told countless times that storing credit card data in a MySQL database is a terrible idea, even if encrypted in PCI compliant secure servers.

What service in 2022 can I use that has something like an API, and with which I can securely store and retrieve credit card info? Validating it before storing it would be awesome, but I can do that in an extra step if necessary.

securityOrange
  • 913
  • 4
  • 12
tony
  • 231
  • 1
  • 3
  • 38
    Isn't the whole purpose of the CVC/CVV codes that they *aren't* stored long term? – Grant May 26 '22 at 15:07
  • 6
    If the database gets decrypted on boot, then that encryption won't stop anyone from reading the database if they get access to the server. – svin83 May 26 '22 at 15:49
  • 5
    "Storing credit card data in a MySQL database is a terrible idea" close but not quite. The correct statement is subtly different: "*properly* storing credit card data in a database is *hard*". Also note that as Grant hinted storing CVC/CVVs is not PCI-compliant. – Jared Smith May 27 '22 at 15:51
  • I have a dynamic CVV that is only valid like an hour (e-ink display for the CVV on the card itself). The scheme is dead on arrival. (https://www.creditcards.com/news/dynamic-cvv-credit-card-security/) – Bruno Rohée Jun 01 '22 at 09:45

2 Answers2

64

What service in 2022 can I use that has like an API in which I can securely store credit card info and retrieve it at a later date for manual processing?

Pick a credit card processor, any credit card processor... They will have a service named "Tokenization" where:

  1. You give them the credit card details
  2. They give you a "token" back
  3. All future use of that card is done by sending them the token

The advantage of this is that all the work of properly encrypting the card info falls upon them, all you have to do is store those tokens and use them in lieu of the card details.

If you decide you want all those numbers back, you can request detokenization, for some reasonable fee. But it's better just to leverage the tokens; detokenization is usually triggered by a merchant switching to a different processor.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 9
    I'll note that using a hosted tokenization service (i.e., so that your server never has even ephemeral access to cardholder data) tends to substantially reduce your compliance burden (i.e., this approach may be eligible for SAQ A rather than other more onerous assessments). – Brian May 26 '22 at 20:59
  • 24
    Not just the _work_ falls on to them but also the _liability_! – davidbak May 26 '22 at 22:18
  • 8
    Yeah, many providers give you even frontend library so that the card details **never** pass through your server, even "temporarily"... so you have no risk of storing them accidentally in logs, temporary files etc. and even if your backend server is compromised they can only see the tokens not the actual card numbers, which means they cannot use that information on other systems but the worst they can do is buy from your store/service. – GACy20 May 27 '22 at 07:13
  • How are those tokens used? The full card details can be used everywhere if stolen, what restricts usage of the stolen token? – Rsf May 27 '22 at 13:07
  • 4
    @Rsf the token is generally tied to the seller. If the seller is compromised and this leads to any money changing hands, this would be between the victim and the seller, not the attacker or any other party. – James_pic May 27 '22 at 16:05
  • @Rsf: As I understand it, it's like having the latin-1 byte for "A"; there are encodings for where the byte (IIRC, it's "26", or "52"?) maps to "A", but if you threw "26" at a encoding for Kanji or the Indian alphabet, you're not going to be sending the byte for string "A" - and as a result, the token likely won't map correctly to the same credit card details of a different seller or processor. (In this example, Unicode doesn't exist yet). – Alexander The 1st May 28 '22 at 15:10
8

What you suggest you will find is against the card scheme rules that are incorporated into the contract that you agree to with your processor or acquirer. As @gowenfawr suggests, use a payment service provider (PSP) that provides you with a token and then use that PSP's API to use the token to charge the card, not "manual entry on a separate system". Also PCI DSS prohibits the storage of CVC2 after authorization.

withoutfire
  • 1,000
  • 4
  • 7