4 ms·

> This means that their credit card details never hit your server. One thing I've been seeing recently is that some implementations using Stripe DO have the CC

> This means that their credit card details never hit your server. One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers. It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen. For Stripe it might perhaps be worth considering denying all payments from non HTTPS pages for this reason. It forces the merchants to have an SSL failsafe. Also with CC info being entered on your site, it's presumably trivial for the site itself to record the CC numbers. Trust is the issue here, I'm not going to be entering my CC number on a site I've never heard of, with no reputation. Stripe doesn't solve this issue, Paypal does. Stripe looks wonderful, but it's not going to be suitable for everyone.

MBCook 14y ago
I worked on something with credit card processing a few years ago. As I remember, it doesn't really matter if the details hit your server, but the point is you absolutely can not save them. No putting them in a DB, no putting the in a log file (not even the last four or something like that), nothing. So if your form takes the numbers in, you make an API call, and then you blank them in memory you were OK. If you put them in the user's session, you were in trouble. It's all insanely complicated, and the only good solution is "don't do it." There's a good reason people use things like Stripe, PayPal, Authorize.net's CIM (where they store it and certify that they are PCI compliant).
- saikat 14y ago
  To make sure there isn't confusion here, having card details go through your server, even if you aren't saving them, still can lead to certain PCI compliance burdens (e.g. you may need to get an audit from a PCI auditor verifying this). Having the card never go to your server is the best way to make sure you are PCI compliant, as you mention.
  - MBCook 14y ago
    Ah, thanks. Like I said, I wasn't sure. We made sure we were PCI compliant, but I wasn't in charge of that by any means.
  - vampirechicken 14y ago
    One component is the transit security -is the data safe from interception in transit (on the network). The other component it security of the data at rest - is the data safe from interception if it comes to rest on your server (sessions, databases, etc.). From data security standpoint is is easier to let somebody else do it, but end users tend to have a less satisfying checkout experience.
- modoc 14y ago
  This is wrong. You still need to be PCI compliant even if you don't persist the CC data. There are a few bullet points you don't need to worry about in that case, but the vast majority still apply if the system has anything to do with credit cards (such as the details hitting your server).
- deleted 14y ago
  [deleted]
- lsh123 14y ago
  Please read stripe's TOS - your application is REQUIRED to be PCI compliant.
  - MBCook 14y ago
    I think I know why I got this wrong. There are multiple levels of PCI compliance, right? I think we used services that allowed us to not have to be compliant with data at rest (since we didn't store it), but only the data in transit (or whatever the equivalent term is). This is by no means my area of expertise (as I have accidentally proven).
    - lsh123 14y ago
      Absolutely, there are different levels. However, for all levels you have to do some work to achieve PCI compliance (and overall security of your system). There is no magic in this world :)
      - snowwrestler 14y ago
        True, and the thing about PCI is that many apps probably could benefit from being forced to do this type of work.
ceejayoz 14y ago
> One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers. Only if you do it wrong. From the Stripe docs: "The only thing to note is how input fields representing sensitive card data (number, CVC, expiration month and year) do not have a 'name' attribute. This prevents them from hitting your server when the form is submitted." > It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen. Again, SSL is covered by the docs. Stripe says you need it. Not that you should consider it, or that it's a bonus, but that you need it. https://stripe.com/help/ssl https://stripe.com/help/ssl
- TomGullen 14y ago
  Can't they deny all requests from non HTTPS pages then?
  - vstm 14y ago
    No, I think there is no way to detect if the HTTP-request to the server which makes the API call is made via HTTPS or not. Except if their libraries detect that on your side and block the API call there, but of course that can be easily circumvented. They can only enforce that HTTPS requests are made to their API.
    - mikeash 14y ago
      Detecting it on your side and blocking the call there would still be really useful. Most people who use HTTP instead of HTTPS probably do so by accident or out of ignorance, and detecting that during development and telling them to fix it would be useful.
saikat 14y ago
Yeah you are right here that it is still possible for our users to mess things up. We do things to try to keep merchants from accidentally sending card numbers to their server (e.g. the default example form makes this hard to do, and most people simply copy and paste this form). It's an explicit decision we've made, though, to leave control in our users' hands as many people seem to like the flexibility to have their checkout experience stay on their site and be designed by them. But we think about where to draw the lines here a decent amount.
jusben1369 14y ago
It's worth noting that we're talking about "degrees" of PCI compliance vs "I'm on the hook or I'm not on the hook" Implementing Stripe so that the data never touches your servers still requires you to complete a SAQ-A. That's just a LOT easier than if you are handling the data and have to complete a different SAQ.
- lsh123 14y ago
  there is no magic in this world (even if stripe's marketing team wants you to believe that there is)

MBCook 14y ago

I worked on something with credit card processing a few years ago. As I remember, it doesn't really matter if the details hit your server, but the point is you absolutely can not save them. No putting them in a DB, no putting the in a log file (not even the last four or something like that), nothing. So if your form takes the numbers in, you make an API call, and then you blank them in memory you were OK. If you put them in the user's session, you were in trouble. It's all insanely complicated, and the only good solution is "don't do it." There's a good reason people use things like Stripe, PayPal, Authorize.net's CIM (where they store it and certify that they are PCI compliant).

saikat 14y ago
To make sure there isn't confusion here, having card details go through your server, even if you aren't saving them, still can lead to certain PCI compliance burdens (e.g. you may need to get an audit from a PCI auditor verifying this). Having the card never go to your server is the best way to make sure you are PCI compliant, as you mention.
- MBCook 14y ago
  Ah, thanks. Like I said, I wasn't sure. We made sure we were PCI compliant, but I wasn't in charge of that by any means.
- vampirechicken 14y ago
  One component is the transit security -is the data safe from interception in transit (on the network). The other component it security of the data at rest - is the data safe from interception if it comes to rest on your server (sessions, databases, etc.). From data security standpoint is is easier to let somebody else do it, but end users tend to have a less satisfying checkout experience.
modoc 14y ago
This is wrong. You still need to be PCI compliant even if you don't persist the CC data. There are a few bullet points you don't need to worry about in that case, but the vast majority still apply if the system has anything to do with credit cards (such as the details hitting your server).
deleted 14y ago
[deleted]
lsh123 14y ago
Please read stripe's TOS - your application is REQUIRED to be PCI compliant.
- MBCook 14y ago
  I think I know why I got this wrong. There are multiple levels of PCI compliance, right? I think we used services that allowed us to not have to be compliant with data at rest (since we didn't store it), but only the data in transit (or whatever the equivalent term is). This is by no means my area of expertise (as I have accidentally proven).
  - lsh123 14y ago
    Absolutely, there are different levels. However, for all levels you have to do some work to achieve PCI compliance (and overall security of your system). There is no magic in this world :)
    - snowwrestler 14y ago
      True, and the thing about PCI is that many apps probably could benefit from being forced to do this type of work.

ceejayoz 14y ago

> One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers. Only if you do it wrong. From the Stripe docs: "The only thing to note is how input fields representing sensitive card data (number, CVC, expiration month and year) do not have a 'name' attribute. This prevents them from hitting your server when the form is submitted." > It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen. Again, SSL is covered by the docs. Stripe says you need it. Not that you should consider it, or that it's a bonus, but that you need it. https://stripe.com/help/ssl https://stripe.com/help/ssl

TomGullen 14y ago
Can't they deny all requests from non HTTPS pages then?
- vstm 14y ago
  No, I think there is no way to detect if the HTTP-request to the server which makes the API call is made via HTTPS or not. Except if their libraries detect that on your side and block the API call there, but of course that can be easily circumvented. They can only enforce that HTTPS requests are made to their API.
  - mikeash 14y ago
    Detecting it on your side and blocking the call there would still be really useful. Most people who use HTTP instead of HTTPS probably do so by accident or out of ignorance, and detecting that during development and telling them to fix it would be useful.

saikat 14y ago

Yeah you are right here that it is still possible for our users to mess things up. We do things to try to keep merchants from accidentally sending card numbers to their server (e.g. the default example form makes this hard to do, and most people simply copy and paste this form). It's an explicit decision we've made, though, to leave control in our users' hands as many people seem to like the flexibility to have their checkout experience stay on their site and be designed by them. But we think about where to draw the lines here a decent amount.

jusben1369 14y ago

It's worth noting that we're talking about "degrees" of PCI compliance vs "I'm on the hook or I'm not on the hook" Implementing Stripe so that the data never touches your servers still requires you to complete a SAQ-A. That's just a LOT easier than if you are handling the data and have to complete a different SAQ.

lsh123 14y ago
there is no magic in this world (even if stripe's marketing team wants you to believe that there is)