I'm using Paypal Pro and direct CC payments. What security measures should I take besides SSL?
I would take a look at guidelines for PCI compliance -- which is all about securing, processing, and storing online payments. If you follow these rules, you should be set.
Suggested reading:
PCI security standards
Dealing with passwords
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
I'm doing a grad-school software engineering project and I'm looking for the protocol that governs communications between ATMs and bank networks.
I've been googling for quite a while now, and though I'm finding all sorts of interesting information about ATMs, I'm surprised to find that there seems to be no industry standard for high-level communications.
I'm not talking about 3DES or low-level transmission protocols, but something along the lines of an Interface Control Document; something that governs the sequence of events for various transactions: verify credentials, withdrawal, check balance, etc.
Any ideas? Does anything like this even exist?
I can't believe that after all this time the banks and ATM manufacturers are still just making this up as they go.
A shorter question: if I wanted to go into the ATM software manufacturing business, where would I start looking for standards?
Well, there are lots of interbank networks. I would guess that each of them communicate differently. The stickers on the ATM (Cirrus, STAR, Pulse, etc...) identify which network the machine participates in. I do believe, though, that the "structure" of the message is dictated by an ISO standard. Cirrus is a Mastercard owned network and PLUS is a Visa owned network... I'd scour their sites to see if they publish any API details.
Edit, by request:
Have a look at the following ISOs 15022, 20022, 9362 and 4217 -- http://en.wikipedia.org/wiki/Category:Financial_routing_standards
ISO 8583 is dominant.
Also, take a look at EMV.
The ATM to bank link can be proprietary or standard. It is only upstream where inter-organisation wire level interoperability is needed, that standards become always necessary.
ISO 15022 definitely doesn't cover ATM to bank. So far, it covers further upstream. And is now superseded by ISO 20022 - "originally named ISO 15022 2nd edition".
ISO 20022 covers the total scope of financial services, and acts as a super forum for ISO financial services protocols.
There are two basic protocols, ISO8563 and IFX (a financial XML subset) but many banks us protocols supplied by the vendor, because these include Device driver protocols that drive the ATM 'States', There is also a reporting protocol where the ATM reports its cash and usage statii.
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.
Has anyone got a tutorial up on getting your own smartcard and getting pkcs#11 working on it? In Linux? (Windows would be fine too).
Most of the vendors seem to assume you'll be wanting enough for your whole company, not one or two.
This heavily depends on the driver and application you use. We use OpenSC/OpenCT for all non-Enterprise Smartcard uses. They have decent documentation.
Yes, check out what OpenSC supports.
Make sure that you know what you want - USB tokens or full-size smart cards. There are pros and cons with both solutions - USB tokens require drivers, often by the manufacturer, to use on some platforms (eg Windows7 or OSX can be troublesome). But they are easy to use once set up and sometimes offer better performance than ISO smartcards. Casual smart cards on the other hand have also contactless interfaces and can be used with pinpad readers which provide higher security than USB tokens.
If you're into fancier features and may want to extend your card infra further than just pkcs#11 crypto, javacards might be useful (OpenSC can not work with JavaCards directly but certain applets are supported, like Muscle) Otherwise look for a supported card operating system.