This is a different question but what I am trying to do is avoid PCI compliance on my end and transfer that issue over to the customer. This will deal with the transfer of credit card numbers. I am wondering how you can create an application like a website but make is so a customer can download it to their computer to use it.
The application would be connected to a API where the credit card data would be given to a credit card processor. Is this possible to do? Can I avoid using a server of my own? If so what suggestions might you make? Can it be done using react? Node? do I have to use Python? Hope this is enough information to understand.
Tim,
If I am understanding your question correctly, you goal is to provide credit-card acceptance as a function to your customer and avoid PCI compliance. If your website includes a redirect or iframe to a processor, then your customer would need to complete an SAQ-A or SAQ-A EP for their compliance.
If you are a maintaining these sites, especially if you have remote access, then you are service provider and would need to complete the relevant sections of SAQ-D. If you build the website and leave it up to your customer after that, you have no obligations under the PCI DSS.
I attached a link to the PCI SSC's website for your reference.
Best of luck
Related
I have a form where I collect the credit card information, send it over https line to my server. In the server, I am using Stripe PHP library to generate a token and store it in my database. Can you please suggest me whether I have followed PCI Compliant or Is there any PCI checklist available in the web?
Thanks,
Raja K
In short, no, this is not compliant. By sending raw card data to your servers, you are responsible for the highest burden of PCI compliance, the SAQ D. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant.
The easiest level of PCI compliance is a Pre-filled SAQ A, which you can use if you use Stripe's frontend libraries to tokenize card data. I would recommend looking into Checkout or Elements to see if they fit your needs.
With Checkout or Elements, Stripe's libraries will tokenize a card for you, and you can send that token to your servers to create a charge. This means that the standards for PCI compliance no longer apply to your servers, as they don't contain sensitive card data.
You can read more about the different levels of PCI compliance when using Stripe here:
https://stripe.com/docs/security#validating-pci-compliance
We're moving away from a hosted e-commerce platform and need to migrate 50000+ customers, ideally keeping their passwords intact.
I requested the customer data(including encrypted passwords and salts) from our current host and they refused saying that it is against PCI compliance.
How would you provide this data to a second party while keeping to PCI best practices?
I've tried searching but I can't find the relevent information or PCI documentation for this use-case.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm new to PCI and would like to use Stripe as my payment gateway. They don't charge monthly fees, and have a good php system to send funds from site to Stripe. Right now I know I can allow customers to put in their card information, use Stripe's framework, and allow the card information disappear. That's fine but my question is:
If I want to store card information in a database for using in Stripe's PHP framework, how do I learn to do it legally?
If you use their Stripe Javascript client to send credit card information to them, what you'll be storing in your database will be a token which represents the client and their credit card, not an actual credit card. If you then ensure that the page where you collect the credit card info is served over HTTPS, you should be PCI compliant.
Using Stripe.js
Being PCI compliant using Stripe
Why would you ever want to do that though?
The beauty of any payment gateway is that you don't have to bother or worry about storing your customers sensitive data, instead you integrate the API with your data layer and consume it as if it was right out of your database.
Stripe provides you with everything you need, their API is very well documented so there really isn't any reason to not be using it in the way I just described.
The simplest way to stay PCI compliant is to never store any card information in any database. Stripe can store the card information for you by using a customer, and attaching card(s) to those customers. You easily access these customers then and charge their card. All you need in your database are the customerId's which keeps you from getting into any PCI issues.
I wanted to create J2ME application, in which the application should work only with the SIM card that was used during installation. On SIM card (GSM) change the application should now work.
For achieving this, i thought of taking an signature of the simcard and save it in a persistent storage. On every start of the application the signature can be verified. Any idea of how to implement this.
Thanks in advance
The 'SATSA' (Security and Trust Services API aka JSR177) could be used from your J2ME application to communicate with the SIM. You could send '3GPP TS 11.11' commands to obtain the IMSI (select file DG_GSM, select file EF_IMSI, read binary).
Drawbacks are: (1) You're talking to the SIM on a relatively low level of abstraction (the ISO7816-4 layer); (2) Not all handsets support JSR177 at the moment.
I believe this is not possible. If it was possible with a specific phone it would not be possible in a generic way.
For ATT in US, for J2ME apps, the handset embeds "CarrierDeviceId" in the Jad file. This is unique per SIM card. So, if something similar is available to you, just read this Jad parameter the first time the app starts, save it to RMS or send it to server. Now each time the app starts, you can verify this number matches, and thus verify the SIM card is same.
You can also try obtaining the phone number that is tied to the SIM card and thus verify the old SIM is being used.
What forms of e-commerce compliance such as PCI-DSS apply when the card details are processed by a third party such as Paypal?
Am building a bespoke shopping cart system that uses Paypal Express, so the card details never hit my server. I do however retain customer details so what compliance - both at a code and hardware level - must or should I be adhering to?
According to the PCI DSS, you only need to encrypt customer details if they are stored along with the PAN (aka credit card number). Since you aren't storing or transacting the PAN, there should be nothing extra you need to do.
See page 5 on the PCI DSS:
https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
If credit card data never physically hits your server (including RAM due to a form post) then PCI-DSS does not apply. Outsourcing your credit card handling to a compliant third party is by far the easiest way to be compliant yourself.