My source is that I work in a payments backend software engineering team at a large company (FTSE 100) that provides an ecommerce platform for multiple medium-to-huge retailers worldwide. And yet, even at such a massive scale, neither our software nor let alone our partnered retailers ever even see the customer credit card number. It's not that we pass it directly to the many PSPs that we integrate with. Rather, only the PSPs' own systems actually see it. And yet, if you were to shop online on any of our retailer partners, as a customer you would still have the illusion that you are giving the actual merchant your number.
Could a non-PCI-compliant merchant ask you for your credit card number and store it themselves? Well, technically yes. But then they would not be able to do any legitimate transaction using it, as they have no way to use card numbers to get money into their bank account without a PCI-compliant PSP performing the transaction.
Could a non-PCI-compliant merchant integrate with a PSP in such a way that they send the inputted card number to the PSP [0] rather than the PSP receiving it directly? No, the PSP would laugh in their faces at the suggestion.
Could a non-PCI-compliant merchant ask you for your credit card number and details and then use them to buy stuff in your name for themselves? Yes, but "non-PCI-compliant merchant" is a very bad euphemism for "online scammer".
[0] One exception being MOTO (Mail Order/Telephone Order) transactions, but they are a specifically regulated case which, by its very name, is by definition not applicable to online card input.> Tokenization is the process Stripe uses to collect sensitive card or bank account details, or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. You should use our recommended payments integrations to perform this process client-side. This ensures that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way.
> If you cannot use client-side tokenization, you can also create tokens using the API with either your publishable or secret API key. Keep in mind that if your integration uses this method, you are responsible for any PCI compliance that may be required, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer's information is not sent directly to Stripe, so we cannot determine how it is handled or stored.
So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. If you suspect that a merchant may go through the trouble of becoming PCI compliant only for the sake of being able to get customers card numbers for possible future malicious use, or do it in such a shoddy way that a malicious employee will be able to steal card numbers, you might as well just stop trusting online card payments in absolutely all cases, including Apple Pay.
I really hope that your job at that security provider is on marketing, because this is a hell of a bad mindset to work with security.
Their point extends to the fact that there are other ways of exchanging payment data that would not allow a malicious recipient to reuse that data illegally.
> So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard.
What others in this thread are arguing is that sharing CC details with anyone is a stupid way of doing payments. It doesn't matter if you're interacting with a PSP or otherwise. You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.
It involves recurring audits of all systems in contact with cc information.
While I've never used stripe, i doubt they'd let you use that API without the certificate, as they wouldn't be able to do the aquiring for illegitimate transactions such as that. They could lose their status as an aquirer if they did that knowingly, and that would make it impossible to process any visa/Mastercard transactions.
You're more likely to encounter a simple scam/phishing site then a legitimate shop that let's cc information onto their servers. And that's honestly the only danger apple pay protects you from.
He says:
> You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.
He’s advocating for a more secure one-time way of making a payment.
It would be more secure since it’s one-time and could not be reused even if the merchant didn’t use a pci compliant design
> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.
How do you know as a client the merchant doesn’t have a skimmer embedded in their payment page? Or that they don’t post directly to their servers (whether accidentally or not)? Are the PCI police going to catch them? Maybe they want to store cards to process later and don’t know or care about pci.
The problem is using the same details for every transaction in a loosely authorized way.
In a perfect world the merchant won’t have access to the card details (like with one-time payments) and everything would go thru a provider with a preauthorized payment. But we don’t live in that world right now.
Are you talking about trivial e-commerce transactions that you could make with Shopify? Yes, you could embed a payment gateway here. However, this is hardly universal or the norm.
In an actual application, you're going to have some API layer over the processor you use. You don't store these credentials, but you do pass them over your API layer and could easily intercept them.
The input of all payment method data by the customer takes place either in PSP-hosted fields, on an iframe of the PSP front-end, or via a PSP-provided SDK or drop-in UI, in such a way that our software never sees the introduced data. All we see are the sanitised details (card type, BIN, and last 4 digits) that the PSP then sends to us.
Merchant doesn't pass your information to the PSP, you are actually talking to the PSP directly.
This usually works by the PSP embedding iframes for the CC fields on the merchants site (so you're inputting directly to e.g. stripe.com)
From a technical perspective, no, nothing is stopping the merchant from asking you for a string of numbers and a month/year date, storing it, and believing that "technically" they can send it to the Stripe API to charge you.
That's when they will realise that, from a business perspective, there absolutely is something stopping them: that they literally cannot do any business whatsoever with your CC details directly, unless they are fully PCI compliant to the same level as an actual PSP.
What stops a business from doing the same thing?
Some large merchants do take the details directly, but they typically have to go through all the PCI compliance hoops and maintain that.
There are exceptions, but most of the time the merchant does not see your credit card details.