Hacker News new | ask | show | jobs
by HNer 5594 days ago
I work in both setting up merchant accounts and offer PCI compliance services. Penetratation testing and something called the SAQ WIZARD which makes the SAQ understandable.

The pain involved is high here are some quick tips:

1) most new startups might as well forget about applying. Unless you have prior trading history which you can prove your chargebacks are < 1% then you will most likely get a NO.

2) The business volume should be at least 5K + per month to make if worth your while (and theirs) and figures below this will probably not be worth their while = a NO.

3) Trying to get a good rate is only going to be possible if your a mum a pop store selling shoes etc., anything online will generally be high risk and have fees north of 3.5 %

4) if your transaction value is high > 500$ + then you will be high risk.

5) anything travel = high risk

6) video, gambling, adult, coupons, gift vouchers, warranties, etc are all a general NO.

7) dating = very high charge backs, block every Proxy IP and non UK non USA. Or all markets you are not targeting.

8) PCI compliance is easy if you use the gateways checkout page, However, if you want to incorporate payments direct into your own site, thus using the API (needed for recurring billing or for repeat clients where you don't want to ask for card number again and again) then PCI compliance is a big task, making sure your servers can pass about 3k5 tests and about 400 questions and standards adopted as part of the SAQ (self assessment questionnaire) + you will need to make sure your app is secure from sql injection etc. etc.

2 comments

It's all about the liability. Ran into the same thing when trying to rent out desks (coworking). Since we're an intermediary we can't bare the full responsibility: the actual things we rent out are outside our control. We were denied because of that. Luckily most consumers here in The Netherlands don't have credit cards, so not having CC checkout is not a big deal, and businesses are accustomed to paying invoices within x number of days. The number of invoices that get defaulted on is worth the risk.
I've never gotten a really solid response on someone in the know about this, so I'm curious about your thoughts about PCI compliance while using APIs similar to Authorize.NET's direct post method (http://developer.authorize.net/api/dpm/), but I've seen similar setups referred to as postback or other names.

From my developer's perspective using this setup, my application no longer "processes, stores, or transmits" credit card details as the PCI spec reads, so my server/app should be out of scope for PCI compliance, right?