When done right (big emphasis on the done right part), the company that is charging you say Patreon, doesn’t keep all of your information, they might keep the last 4 of your card number, name and zip code for example.
Simplifying a lot, They pass the rest onto a payment processor who then does the transaction and returns something to say it was successful. Patreon can than use that return value to charge you next month, basically hey remember that transaction? yea can you do it again, here is the proof it was authorized.
The rules governing all this are called **pci compliance** and are pretty complicated and require a lot of checks which is why most companies use a payment processor like paypal, stripe, visa etc
They wouldn’t be hashed because hashes are one-way. They will be encrypted.
Pretty much all companies that aren’t payment processors will use a payment processor company to do the actual transactions. In order to be able to process credit cards you need to be PCI compliant which involves a lot of rules and regulations. Most companies don’t want to deal with that, and need to ensure that credit card numbers do not pass through their own servers.
What the payment processor does is they take the credit card info and give the company come kind of token that is associated with the card. The company can issue charges against that token. The token is only valid for that particular company, and can be revoked so it is no longer valid. That’s what happens when you cancel a subscription, that token gets revoked, so it can no longer be used. This keeps is separate from your actual credit card number, so you don’t need to replace your card to ensure it can be charged.
Even with all that, it’s still technically possible for an employee at the payment processor company with sufficient access/permissions to get the details. But that’s true with in person transactions too. People give credit card numbers over the phone all the time, and there’s nothing stopping the person taking the call from writing it down. And checks are even worse. because there isn’t any regulation on keeping that information secure at all.
The entire banking industry works more on fraud mitigation because at a fundamental level prevention isn’t possible. It’s why banks have sophisticated AI systems to detect “suspicious” transactions. I’m pretty sure they also help track down thieves and fraudsters because it’s in their best interest. The overall idea is to try to make the risk not worth the reward.
Edit: Explaining like you 5:
The server multiplies the credit card number by another (secret) number and stores the answer and deletes the credit card number.
When the server needs the real credit card number again it takes out the secret number and does the division to get the original credit card number.
Only the server (company) knows the secret number so if the server is hacked the hackers will have a difficult time figuring out what the secret number is.
This is an oversimplification, this is how I would explain it to a five year old.
There is a set of standards call Payment Card Industry Data Security Standard (PCI-DSS) which establishes all the rules on how credit cards and related data are managed. This applies to everything from the back-end servers to the credit card machines themselves. PCI-DSS basically establishes two ways servers can manage their data – through encryption or tokenization.
Tokenization is a technology which creates a reversible placeholder ‘token’ for credit cards – so for instance given the card number ‘1111 1111 1111 1111’ you might generate a token ‘9912 3456 7890 1234’. Tokens take advantage from the rules governing credit card Bank Identification Numbers (BINs) and Luhn checks to ensure applications can tell the difference in real cards and tokens. Tokens are widely used for lower security servers – say for a 3rd party vendor doing analytics.
Banks typically create a small set of highly controller servers isolated from the internet that deal with raw credit card numbers. These will be physically enclosed in cages, restricted with firewalls, and require strict rules for access control. PCS-DSS mandates strict rules regarding most aspects of these servers.
Servers inside the restricted credit card environment should use a mix of tokenization and encryption to protect card data. Encryption must be modern, standards-based algorithms – this rules out “new crypto” like block chains or homomorphic encryption. (It should also exclude vault less tokenization technologies, but PCI-DSS isn’t really clear on the issue yet.)
Ideally the only database which would use encryption for storing card numbers would be the implementation of the tokenization systems. Ideally the table structure would use HMAC to create a column of hashes enabling ‘SELECT’ queries, a column of AES-256 encrypted ciphertext for matches, as well as a column of carefully generated tokens based on cryptographically secure randomization.
I work as a software engineer in an online payment processor. I will talk specifically about online credit card transactions but the ideas are similar for physical credit card transactions.
As others have said, if you want to process credit card transactions, there is this standard called PCI-DSS that you need to comply to.
If you just want to accept credit card payments as a merchant, the best way to ensure compliance is to not collect credit card details at all. There is a large chunk of the PCI-DSS that doesn’t apply when your system does not handle credit card details. The next best is to collect and just pass them to a payment processor and not store them persistently. Many payment processors offer one or more features to do so.
One of those features is a hosted payment form. Different payment processors call it different names (e.g. Stripe Checkout) but the idea is, instead of collecting credit card details yourself, you pass the transaction data (currency, amount, etc.) and open a payment form hosted by the payment processor. The buyer enters the credit card details in that form to give them directly to the payment processor. The payment processor then notifies you of the result of the transaction. This way, your system never sees the credit card details.
Hosted payment forms does not apply to recurring payments like a subscription fee where the buyer is not actively going through the transaction process.
An alternative is tokenizing the credit card details. Whether you decide to use a hosted payment form or to collect collecting credit card details yourself, the payment processor can return some kind of token to you. For subsequent transactions you can use this token in place of the credit card details. The payment processor use the token to retrieve the corresponding credit card details stored on their system to complete the transaction.
To ELI5 the already good answers in this thread at a lower level:
Suppose you want to give me some money periodically, but you don’t trust me. How could you give me money without me knowing your card or account details?
One way would be for you to go to the bank, open a NEW account, then give me a copy of the card to that account. You’ll only put money in that account when you want to pay me, so I can’t ever get more money than you wish from it, and I don’t know anything about your REAL account.
The digital equivalents are very similar. The “right” way to handle online payments is to send the user to a payment processor’s page and let the user enter their data there. If they present a valid card, the payment processor gives *me* a magic number that *represents* your card and is only valid if I use it. I store the magic number, and from now on if you ask me to take some money from you I use that number and the payment processor handles the details.
So if someone steals the number from me, it’s not of great use to them because they also have to steal other digital things that lets them identify themselves as me. And even if they do, I can call the payment processor, explain I’ve been hacked, and they will cancel ALL magic numbers they’ve given me immediately.
The payment processor themselves are probably doing the same thing with the bank. When you put the information in, the processor asked the bank if your card details were valid, and if they were the processor got their own magic number representing your account. This *can* be stolen, but just like my magic number it’s only useful if the thief can trick the bank and it’s only useful until I tell the bank it’s stolen.
So it’s sort of like there are a couple of layers of “fake” bank accounts in between the internet and your real account. That way if someone steals information about the “fake” account, while they can cause some harm in a short time period, they can’t learn anything permanent about your account that lets them have long-term access.
Latest Answers