Accepting payments is getting harder

This is good. People are getting fed up with replacing their credit card every six months because some online retailer had a breach. You can outsource payment processing to Stripe, Paypal, Square, Yahoo Store, etc. There's no reason every web merchant should see credit card numbers.

Stripe is in Visa's doghouse right now.[1] Their entry on the Visa Global Registry of Service Providers has turned yellow, with an expiration date of Mar 31, 2015. This means they're having some PCI compliance problem.[2] Visa gradually cranks up penalties until the problem is fixed, or, after about 9 months, just pulls the plug. Visa says Square and PayPal are OK right now. Yahoo is also in the yellow doghouse. (If you're a Stripe or a Yahoo Store merchant, they were supposed to inform you that Visa put them in the doghouse, so you can change vendors. Did they?)

[1] http://www.visa.com/splisting/searchGrsp.do [2] http://usa.visa.com/download/merchants/Bulletin-PCIENFORCE-1...

For what it's worth, PCI compliance as it stands today is complete BS. It provides a false sense of security and most of the PCI ASVs are the scourge of infosec. I can't tell you how many customers we have that use the cheapest possible PCI ASV for "compliance," but then use us in addition for "real security," despite the fact that we aren't an ASV. We've intentionally stayed away from becoming one thus far, actually, because that is a whole political game in itself. [1]

The new requirements are better. Stringent and hard to comply with, but better.

The real solution, as I see it, is to build automated security testing into your SDLC / Dev process. Penetration tests, when done by a good firm like Matasano, are incredibly useful, but lose their value the next time you push code. Building tools like Tinfoil into your CI process makes sure you don't get owned between pen tests.

PCI is unfortunately written by political minds and lawyers, not engineers or infosec folk. This is an unpopular comment, but is true in my estimation. Comply because you must, but please don't treat it as the end-all be-all. Care about your customers' data just a little bit more.

[1] http://bretthard.in/2013/01/the-pci-asv-process-sucks/

Good. There's no love lost between me and companies that make significant money doing PCI assessments (they tend to be the bottom-feeding remora of the infosec economy), but the one criticism you could not level against the PCI certification program over the last 10 years is that it was too hard to get certified.

Use Stripe. Move on.

> The worst offenders however are the requirements that some businesses simply cannot comply with unless they have some serious cash laying around. Examples of this are

>> Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

> and

>> Is external penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)?

Have you ever had a penetration test done? They basically run a load of OSS automated tools, generate a PDF report, and then charge you $1000s. It gives you no real insight and reveals nothing unless you've been a total noob. Why is this so expensive?

Broadening of PCI scope + needlessly expensive compliance = Smells like a large opportunity.

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen, only that vendor can use it anyway. And I could have the option to tell my bank to make it a single use token, or to cancel a multiple use token or to set a payment cap to that token.

That doesn't seem very complex to implement and would alleviate the vast majority of the credit card related problems. I am sure it can be made simpler, have a protocol with redirects to the bank's website that eliminate the need for the client to copy-paste a token, or to have another mechanism with similar effects.

Banks are one of these many industries that don't seem to get technology. They employ massive IT and developer staff but are run by people who don't get it (and to make things worse, are most of the time massive bureaucracies which means that even when they know what they need to do they just can't execute).

I always recommend people build their payments on Spreedly (https://spreedly.com/).

It checks off the boxes for minimizing PCI scope; you store no payment information, and collect none on your website either. You can either do a transparent redirect (your payment form points to a URL on their domain, which redirects back to your site with a token) or an iframe.

Once you collect payment information, which they tokenize and store, you can run charges/auths/refunds against it using any of 81 different payment processors and gateways. Balanced one day, Stripe the next, and whatever startup is popular after them in a year -- without changing any of your payment code.

This is a great article. I would add a couple of data points for context:

- Visa won't come after you. Your merchant account provider is on the hook. They let you process cards so they need to ensure you're PCI compliant. That's how the flow works.

- PCI 3.0 kicked in in January. People reassess annually. So if you reassessed last year under 2.0 standards you're still good until your renewal comes due. That's why this is slowly creeping across the payments space in terms of realization.

- The card networks saw longer, sustained ongoing fraud happening in online commerce from .js or transparent redirects than they did from hosted payment pages. So the big change in PCI 2.0 to 3.0 was this idea of wanting to make it harder to completely build your own custom payment pages vs using a hosted payment page. HPP's are SAQ-A and customized payments pages - A EP

- iFrame's and checkouts are really trying to be the best of both worlds. That's why they're currently treated as SAQ-A. There was definitely a lot of thrashing around how they would be treated when the 3.0 specs were being drafted and published.

Again, I really enjoyed the article and appreciated Spreedly being included as a reference. I would agree with the major premise that in general merchants are unaware that the way they implemented their payments pages now mean they're in greater scope and that the providers aren't doing a good job educating them. It's an open secret in the industry that many payment gateways add a (pure margin) fine for $20 to $50 per month onto your account if you don't have valid certification. In a low margin business that reduces motivation to push small and medium merchants to ensure they're PCI compliant.

Stripe plans to use the iFrame "loophole" to enable Stripe.js customers to qualify under SAQ A-EP as mentioned on their website[1]:

> The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe.

Can someone help me understand how this is practically any more secure than the way Stripe.js currently works? It sounds like the intention of the iFrame exception[2] is to allow a payment form to be loaded, completed, and submitted to a compliant server all within a visible iFrame. From what I can tell, the "compliant" version of Stripe.js just submits the data (similar to the traditional way) via an invisible iFrame - the form is still hosted and completed on the (likely) non-compliant server.

If that's the case, then I'd expect the "loophole" to go away soon and current Stripe.js users will have to adopt a payment flow similar to Stripe Checkout; in other words, it will be obvious that Stripe (a third party) is being used because the end user will be interacting with a form (or part of a form) completely hosted on Stripe's servers.

For companies using Stripe to avoid PCI compliance with self-hosted payment forms, this essentially transforms Stripe into another PayPal checkout-style service.

[1] https://support.stripe.com/questions/what-about-pci-dss-3-0

[2] https://www.pcisecuritystandards.org/documents/Understanding...

This whole area is a big ole platform problem.

Credit cards are a bad platform to build on. The duopoly structure is a bad platform for gradual improvement and the regulatory environment is a bad platform for innovation.

We have deeply entrenched kick-it-forward allocation of responsibility and fixes to serious problems are characterized by firefighting, designed-by-committee compliance, cover-your-assness and such. All the hallmarks of a poorly functioning market, poorly functioning organization and general pathologies that occur whenever the way we organize is wrong.

Leaving bitcoin aside,^ I think the fundamental problem is having CCs play the role they do. Instead of customers sending merchants money, merchants request money from CC companies. That is a bad system.

^The reason bitcoin is difficult to insert into the conversation is because it has so many big hairy goals. Government power over money. Macroeconomic theories of monetary policies baked in… Its a big interesting project, but the problem discussed here is only really a subset of what bitcoin is about so it's kind of a tangent.

As a small business taking card payments, we're far more concerned about the absurd rate of failure of perfectly legitimate charges than anything PCI-DSS say. We lose more customers to Stripe charges failing than any other reason, by a considerable margin, and it seems even Stripe don't actually know why because it's organisations further down the line making these decisions.

The whole card payments industry is broken, and the sooner the growing direct payments industry kills off the credit card giants, the better.

One of my side projects is a membership/subscription model Primary Care medical practice, and uses a third-party payment processor and we were recently audited by one of the large payment card issuers.

There was a finding that the third-party processor - which we specifically choose because many of their clients were major gyms with similar monthly membership models - was improperly processing our members payments. If I recall correctly, there is one standard for one time payments and a different standard to be used for recurring payments. A subscription model like ours allows our subscribers to use either, but the third-party processor used the one-time payment standard to process both one-time payments and monthly recurring payments. Even though recurring payments was a major selling point of the processor, when it came down to it, they were not even aware of the distinction and aware of the separate standard. We were actually quiet fortunate in that we had original signature agreements for each and every instance of a member who agreed to the recurring automated payment, but as I recall without those agreements there may have been some kind of repercussion.

Anyway it is a cautionary tale that just because you use a third-party, even a reputable one that serves national franchises, does not necessarily mean they know what they are doing.

This is a fantastic example of why companies like Stripe are going to come out ahead.

Other companies are basically telling you "deal with it", while Stripe is giving you documentation and rewriting their software for it.

The biggest thing to remember when dealing with PCI DSS is that it's not the law.

Your PCI obligations come out of a commercial agreement that you have with your processor, which comes out of commercial agreements they have with VISA/MC/et al. That's not to say that it's not a well-defined standard that you're going to end up having to follow in some way, but rather that statements like "Both Litle and Recurly flat out say that you need SAQ A-EP" have more wiggle-room than it would sound like, depending on the rest of the deal you're presenting them with.

If you're a Level 3, I'd argue the goal should be to keep yourself on SAQ-A - the methods of which are pretty well-understood now. Pick a vendor which has a tokenization service designed to be hit from JS (they all work the same way at their core - download JS which contains an implementation of RSA and a public key, browser-side encrypt the CHD using that, send it off, get back a token). Put your payment form inside an iFrame which is served from a PCI-compliant host (like S3). Once tokenization is complete, send the token from inside the form back out to the containing page using postMessage or in the querystring.

Do all that, and you're fine to stay on SAQ-A (https://www.pcisecuritystandards.org/documents/Understanding...):

Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')

Will they change PCI DSS again to remove the iFrame rules? Maybe, but given the speed the PCI council moves at (and the warnings they give before changing things), I'd deal with it then.

Lastly, if you're thinking of building a service which white-labels credit card processing and sells that processing as a service which your customers can then resell...don't forget about PCI PA-DSS

Unless you're in the business of money, you shouldn't really be doing it yourself, so the important TLDR is:

> Obviously it’s not fun living in that fear, which is why I believe that services like Stripe, that help you out with these issues, will thrive.

Accepting payments is getting easier, because companies like Stripe will handle the burden of security and compliance.

This move makes sense if you look at PCI's board of advisors[1]- It's a bunch of bank VPs plus the head of security for both First Data and Pay Pal. The people who run PCI compliance are the ones that stand to lose if PCI compliance becomes moot, so they are doing all they can to make it seem like it's the be-all end-all of internet security and that you'd be a fool to trust an online merchant that wasn't PCI compliant.

Interesting point about making vendor specific security tokens for internet transactions in an earlier comment. That would quite obviously help tremendously in the case of a breach, however that would put the onus on banks to be responsible for security instead of on merchants, and again the bank representatives on the BOA at PCI aren't going to go for that.

[1] https://www.pcisecuritystandards.org/organization_info/board...

The problem of credit cards is that when you make a payment, you have to give away your private key. No amount of securitisation will take away this fundamental flaw.

This is one of Bitcoin's evolutionary advantages in this space. To send money with Bitcoin, there is no need to expose one's private key. A massive corporation could take millions of annual payments and their paying customers needn't be concerned about their money being at risk. If the entity has poor security, the only people they endanger are themselves.

I have to have a new pen test every time I "add a web server"?

Every time legacy payment processors ratchet up compliance requirements, cryptocurrencies get another little boost. And while it's easy to forget in the US, where credit cards are handed out in boxes of cereal, getting a credit card is an insuperable hurdle of much of the world's population, eg. the estimated 75% of Indians who work in the informal economy and thus can't prove (or don't have) regular income.

This is great that HN is talking about PCI. The problem with PCI and compliance in general is three fold.

1. People don't want compliance [1]

2. People think compliance is broadly applied

3. People don't know where to start

I'll answer these point by point.

1) The reason people don't want compliance is because the security industry claims that Compliance is bare minimum and not enough. If they told you that Compliance was simply doing your due diligence on your sensitive devices, I think the market would have had a software tool to easily get us through the process by now. (I built a "brilliant" PCI tool btw. Link below)

So let me explain to them why I think Compliance is just doing your due diligence and we'll do that by simply asking this question: If compliance is bare minimum and not enough, what is a comprehensive approach available right now to reasonably protect our sensitive data? The security professionals will tell you Risk Assessments and Pentesting often is the best alternative [2]

Their answer is to specifically switch to Risk Assessment and PenTesting often, which is Requirement 11 and Requirement 12 of PCI. Each one of the bullets written is specifically covered by PCI DSS 3.1, including social engineering/phishing attacks that are provided through security awareness training. They're telling me that compliance is bare minimum, yet their suggestion is to do a subset of compliance. Its circular logic. Since its circular logic and nobody has been able to provide me with a reasonable approachable alternative to going above bare minimum, I hypothesize that compliance is NOT bare minimum, but in fact, due diligence.

Think of a fort. Forts had defined compliance checklists in the old times. In a fort, you go through a security rotation of making sure the pot of boiling oil tips over on time. You practice your smoke signaling so that the appropriate people are notified in the event of a wall breach. Were they spending a majority of their security drills taking half their army, launching it against the fort, fixing what fails, and then doing a risk assessment? 

2) A compliance program by definition is only applicable to your sensitive environment. It cannot be applied broadly. Its forcing you to go through the decision making process of asking yourself, "What's most important to protect right now". Only you can classify the sensitivity of your devices. Only you can choose if your code base is sensitive or your employee's SSN is sensitive. But whatever you’ve classified as sensitive must fall under compliance. Let's refresh: Compliance is designed to be applied only to your sensitive data. If you choose to put a non-sensitive devices under a compliance program, then you've specifically applied compliance broadly. 

3) To approach any compliance program, ask yourself 6 questions on any specific device.

1. Does this device store, process or transmit sensitive data (e.g. cardholder/health/SSN)?

2. Is there unrestricted access between this device and a sensitive device?

3. Does this device provide authorization, authentication, or access control to a sensitive device?

4. Can this device initiate a connection to a sensitive device?

5. Can a sensitive device initiate a connection to this device?

6. Can this device administer a sensitive device?

If you're able to answer yes to any of those questions then your device is sensitive and due diligence is required. Let's go back to the fort example. Is there unrestricted access from that boiling pot to the sensitive gold chamber? Does the pot provide access control to the sensitive gold chamber? If yes, then configuration settings of the pot, pulley, oil, need to be recorded and monitored periodically. If no, then its possible that you might have a business justification for not putting as much rigor into recording and monitoring the correct functionality of that pot.

You've already started the compliance process by asking yourself, "Does my laptop initiate an outbound connection to a sensitive device?" If yes, then your laptop falls under compliance and due diligence is required.

Everything else is just record keeping. Create a network diagram of only your sensitive assets. Write down how you rotate your keys on those sensitive assets. Write down what log files you periodically review. Go through a practice run of your Incident Response in case there is a breach of your sensitive asset.

This is a pretty long post and I hope it helped.

Shameless plug, I'm building a tool called ComplianceChimp to guide you through this entire process including recording your procedures with Github flavored Markdown. You can see how I'm using our tool to get us through the PCI Compliance process. [3]

[1] https://news.ycombinator.com/item?id=9510435

[2] https://gist.github.com/akshatpradhan/1573e5f6c1872b6af129

[3] http://cc-stg2.herokuapp.com/compliancechimp/documents/softw...

What service might I use if I needed to fulfill the following requirements:

1) Say I already have a customer -- he already paid a signup fee and we charge him monthly, so he's already put in his credit card information. At a later date, we need to charge him for something other than his monthly subscription fee. This is something he can do himself by logging in, but also something the site administrator needs to be able to do by selecting his account and clicking a button. In this case, we do not want the user to have to re-enter his credit card information; we want this part to be seamless. Is there a payment API that can do this -- random one-off charges against an existing account without the user having to sign into the third-party service himself?

2) Is there a service that charges bank accounts directly -- as in they enter their bank account number instead of a credit card number? Other than PayPal --they seem to be the only one that does this.

It's only getting harder if you have "inline" payment. Honestly I'm glad to see that go away.

We always used "hosted payment page" solution, it's safer, and we've been expecting tougher rules for some time.

If you want to talk about online payment becoming harder, you should address the increasing number of payment options that online stores need to support. Adding to debit and credit cards are bank transfers (which is different in every country), PayPal, invoicing, part-payments, financing, and an almost unlimited number of local option.

Well, I guess it won't hurt if I offer my services for PCI guidance for startups here :-)

One thing to keep in mind is that PCI is a bare-minimum of security "best practices" that aims at validating that a company transacting with payment cards has an understanding of data classification and protection.

nice recap