Comment by rcme
2 years ago
I think you missed the “over the internet” part. When you do a CC transaction over the internet, you give the merchant your CC number and all the other information needed to make a transaction happen. A legitimate merchant may pass that information directly to a PSP, but you can’t deny you’ve given the merchant the information. Surely you’ve filled out a CC form in a website before?
Yes, I have filled out a CC form on a website uncountably many times. I can also deny that I have ever given any merchant my card information (at most, if the merchant was utterly massive, I may have given my information to their own fully-owned subsidiary PSP).
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".
I think you’re confusing what you’re supposed to do (according to PCI) vs. what you’re technically capable of doing. Look at the Stripe’s documentation for creating a payment method [0]. The parameters it takes are card number, expiration, and CVC. Any merchant using this API could trivially save the information for future, malicious use.
0: https://stripe.com/docs/api/payment_methods/create
Please refer to the section just above, in the "Tokens" section. Emphasis is mine:
> 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.
14 replies →
That's actually not how most of e-commerce payment works nowadays. If you use Shopify, merchant doesn't see your credit card. Same for SquareSpace. Same for Salesforce Commerce Cloud / Demandware, where everything is more often integrated with Stripe/Paypal directly and merchant never even see it. Very rare the merchants that will actually "see" your credit card.
Merchant doesn't pass your information to the PSP, you are actually talking to the PSP directly.
You don't send anything to the merchant. The information goes directly to the PSP and the PSP sends a token to the merchant.
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)
People use Stripe’s forms because they’re convenient. It’s not a requirement in any way. Stripe provides APIs to build everything in their provided forms so you can build the functionality into your own site easily.
You are apparently not working in eCommerce and don't seem to know how 99% of merchants work nowadays. Merchants don't integrate by calling the Stripe API. They use a platform and those integrations are built-in. The amount of merchants that are actually building their own integration to Stripe API is a very small %, and majority of them would be very large retailers that have the staff to create their own ecom platform and are PCI compliant. Small/medium retailers for the most part are not working that way.
4 replies →
You’re usually prohibited by the PSP from gathering or storing the CC details directly. You’ll notice you often don’t give the merchant the details directly.
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.