This is correct and the GP is (confidently) talking nonsense.

However the big issue is most normal users would not have the ability to see if they're using an embedded iframe or cross origin JS from Stripe, Braintree, etc.

He is not talking no-sense. He is talking what he perceives as a user.

the same way that when you get a refund, you dont see the money back immediately. What the user doesn't know is that when you pay a business, the same thing happens, and the business don't get the money immediately.

And to pay by credit card feels much more insecure than using paypal or amazon pay, even if it isn't.

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 it 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, only the PSP ever actually sees it. And yet, if you were to shop on any of our retail partners, you would still have the impression that you are giving the merchant your number.

Could a non-PCI-compliant merchant ask you for your credit card number? 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 integrate with the 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. 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? 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.

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.

What point are you even making?

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.

I'm making the point that I work in a department that develops a payment platform for a variety of retailers and has to perform non-trivial integrations with a broad range of PSPs worldwide, covering all sorts of payment flows, including cases in which the PSP itself has had to do new development on their end to cover use cases that they had never come across before. And yet, we do not at any point pass the card details through the API to the PSP.

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.

You are insistently missing the point, and overlooking a series of security flaws just by reasoning that people aren't authorized to exploit them.

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.

I don't think you have paid enough attention to detail when reading my comments to have an informed opinion as to whether I am "missing the point" or whether I am instead talking from in-depth practical experience on the subject.

You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack

No, that is not what I am arguing. Please reread the thread.

Here is a summary of your argument in your own words:

> 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.

As another person that's worked in payment (specifically aquiring) for 6 years: PCI compliance is not a trivial matter as you seem to believe.

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.

What PCI says is irrelevant. The argument being made is that when you enter your CC number into a website you have no idea if the receiving party is PCI compliant or not. There are ways to design a payment systems that reduces this counter party risk.

I’m not sure what you’re replying to?

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:

> 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.

New user joining the fray here. I worked in cybersecurity at a bank for many years. I haven't read all of what you said, because I agree that you're missing the point that someone was making. Right now, I could throw up some kind of merchant page for some homebrew service, and have an HTML form that asks for a credit card number a CVV and an expiration date. That would be illegal or otherwise non-compliant with PCI, absolutely but it's technically doable. Every time that someone types in a credit card number into a website, they have to trust that the merchant they are doing business with is handling that data in a secure and compliant manner. That is the point of the OP.

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.

This conversation is really crazy to me. I’m going to assume these people really do work in payment processing and it explains a lot. Apparently they can’t even properly recognize a potential attack vector let alone mitigate it. If this mindset is common in the payments industry, then it explains why payments are still so insecure.

"But, but, it's illegal". But nonetheless it was a illuminating debate.

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.

Again, merchants don’t integrate by calling Stripe APIs directly out of convenience. It’s more convenient to use an out of the box solution. But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.

> But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.

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.

I had a job waiting tables when I was a teenager when my co-worker got busted for writing down credit card numbers and info when she took the tables' cards to charge them. Apparently she had racked up over 100 thousand in fraud over time.

What stops a business from doing the same thing?

That's like saying you can't steal from the grocery store because 99% of people don't steal from the grocery store.

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.

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.

I've used plumbers and dentists where, over the phone, they collect your CC information, sometimes as a deposit before doing work.

Always made me nervous... are they writing it down? Typing it into their home-made software?

Those are MOTO (Mail Order/Telephone Order) transactions, and follow a different regulation than online card transactions. See here: https://docs.adyen.com/point-of-sale/mail-and-telephone-orde...

> 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.

No. In best case, you’re giving your payment details to a PSP. A couple years ago NewEgg had a javascript skimmer on their checkout page that harvested all their customers payment details for months. Obviously anyone with access and intent could do the same for any payment page.

What prevents me from cloning some product's website and changing the payment form to send me the details instead, which I then submit somewhere else to purchase something online for myself? Not sure why Stripe or PCI is even important here.

(IMO) what GP was arguing for is that we should have a fundamentally asymmetrical form of payment, viz. the information I give for one purchase should not be able to be reused for another purchase, like a one-time token. Imagine if you had to send your private key every time you wanted to purchase something in crypto, for example.