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.
Related
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
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
Is there way how to connect our PinPad card terminal to Unicenta ? I cannot find any info about hw connection to unicenta.
We have this:
http://ingenico.us/terminals/ipp220/
Per their FAQ, they do not support direct communication with terminals (pinpad).
FAQ
Q: Does uniCentra oPOS handle Credit Cards?
A: We don’t integrate with directly attached card payment terminals at this time.
Also, the only payment peripheral listed is the "Magnetic Card Reader".
You may want to research the existing integrated gateways to see if they have a direct terminal communication solution.
Short question: Can I read credit card information with a NFC capable Windows Phone 8?
Long question: How does NFC with credit cards exatly work? The card (or the phone with wallet function) receives a request via NFC and replies with the cleartext credit card information in some standardised format? The Wallet option then aditionally still props some comfirmation dialog before broadcasting the credit card information?
Or is there some handshake encryption going on before hand? Or is there some credit card specific secret code safeguarding the commuincation? Or is there some overlay protocol on NFC for payment? NFC ist just pushing a string over the air as far as know?
If it works, as I think it works, can I tell a Windows 8 Phone, through preferably C#, to read credit card information and display it to me (if the credit card has a chip inside)? Or does maybe Windows Phone 8 disallow access to the NFC reader, or some mystic payment protocol (if such a thing exists). My short web search was very vage on technical details, especially with some sites talking about carrier support for wallet systems, as if some keys would be fetched from somewhere in the web to secure the transactions? I can't really image something like that being standardised accross all credit card issuers.
Can someone give technical insight the way credit card data is transfered and if you can program a phone to read such data.
Contactless credit/debit cards certainly do use NFC (mainly ISO 14443-A, some mainly in France are ISO 14443-B), and their communication protocols follow an industry standard called EMV which has public specs available here: http://www.emvco.com/specifications.aspx?id=223 The cards speak the same EMV both over NFC/contactless as well as through the contact chip (eg the gold thing you insert into a reader) though payment networks tend to do things slightly differently depending on which interface is used (eg sometimes PIN not required via contactless for low amounts, whereas contact might always require a PIN). Also, certain aspects of the protocols are proprietary to the payment networks so the EMV specs don't fully describe everything.
If you search around there are various sites that give some examples of how to communicate with credit/debit cards some over NFC others with an insert chip card, but typically the commands will work the same regardless of the interface. You can buy a USB smart card reader that will do both NFC and insert/contact for http://blog.saush.com/2006/09/08/getting-information-from-an-emv-chip-card/
For Windows Phone you also can talk with credit cards as long as you have a Lumia 830/730/735 etc as the older devices (even the Lumia 930) have an older NFC chip where the driver doesn't support the smart card APIs. You can use the sample code here: https://nfcsmartcardreader.codeplex.com/ to learn how to send/receive APDU commands/responses to NFC cards though that project doesn't specifically have the commands you need for a credit card (though that other link does have the APDUs you need).
And credit cards generally all will let you read their PAN (the account number printed on the front), expiry date, and in some countries even the cardholder name (though in the US for privacy most banks tend to not expose it, instead returning stuff like "VALUED/CARDHOLDER" as the name) without any encryption or keys. It will not however return the CVV2 code printed on the back of the card, which is generally required by merchants to be able to place orders on the internet, and it also generally does not let you clone the card since there is dynamic/encrypted data required to do card present transactions at a physical merchant.
Short answer: No. It's unlikely Credit card would work with WP8.
Long answer:
RFID vs. NFC: As far as I know most credit cards don't have NFC. They have RFID. Which one could say it's a "predecessor" technology to NFC. RFID is mostly non-standardized, has longer range than NFC and only supports one-way communication. Whereas NFC is an evolving standard, can be used in 2cm-4cm range and supports two-way communication. So, WP8 does not support RFID but it does support NFC.
RFID on WP8: All that being said, there's a chance that WP8 could identify some RFID tags. You might be able read byte[] from specific RFID tags in specific WP8 phones. Obviously, that's not recommended.
Secure NFC: One last thing is that some very exclusive partners in some very specific regions will have access to "Secure NFC". Secure NFC is a superset of NFC and adds the feature to store & transmit secure information via NFC from WP8. For example Secure NFC can store a Credit Card number or a bank account number as part of the WP8 Wallet. However, That will only work in regions where the mobile operator issues a "Smart SIM" (SIM capable of running applets), where the developer can author Java based Smart SIM applets, where the developer has an agreement with the mobile operator to deploy those applets over-the-air, where those WP8 apps have been cleared with Microsoft for the WP8 store and where there are dedicated retail HW terminals that can read them.
Sorting out a bit of the above answer of JustinAngel:
RFID is not a predecessor technology of NFC
RFID covers various frequency bands of Radio Frequency Communication (e.g. HF and UHF)
NFC is Near Field Communication and usually covers HF (13.56 MHz)
Many standards fall under HF NFC: ISO14443-4, ISO15693, FeliCa, ISO18092, .....
NFC Forum is trying to unify things and uses NDEF messages to exchange semantic messages
contactless payment on credit cards is based on a contactless smartcard layer.
WP8 allows only exchange of NDEF messages
WP8 does not allow exchange on the contactless smartcard layer (ISODEP==L4==(T=CL))
see the windows proximity api for details or http://developer.nokia.com/Community/Wiki/Use_NFC_tags_with_Windows_Phone_8
Android however gives access to this ISODEP layer
I don't know what credit card information could be retrieved from an app. There is a secure element involved which handles cryptography and stuff. I don't think detailed information on Mastercard payPass or VISA payWave is freely available
Can I read credit card information with a NFC capable Windows Phone 8?
No, you cannot do that. NFC API on Windows Phone 8 is very limited.
May be Wallet API could help you somehow with your project, but this is not about NFC.
Also you could try to use Android devices with NFC, they have more powerful NFC API than WP8.
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.