This is one of those instances where if your volume is < $1,000,000 per annum you probably shouldn't even be thinking about doing your own acceptance of CC data.
Just hand it off, pay a couple of % and get on with doing what you're good at.
So, no, they don't do the audits themselves but they have been audited several times over the last 8 years, and so far they have passed their audits with flying colours.
The people running that business take it very seriously, they process about 150M$US annually and they have it set up so that every customer has their own merchant account.
This is contrary to most IPSP's that multiplex a single (or several) merchant account(s) across many merchants, which I personally believe is a recipe for disaster. For more information on what can go wrong have a look at 'IBill' and 'DMR'.
This does mean that it is much more expensive to set up a customer but the good news is that it actually is a lasting relationship instead of 'until we get yanked'.
tptacek, you're right about life being too short for that BUT in some cases an entity really does need to ensure compliancy.
Note that a really important code issue is buried in the comments here, with DHH following up to clarify: you have to decide whether you want to store credit cards, or enroll them with your payment processor gateway.
I have an opinion here, as one of the people the payment industry sends out to punch unwitting developers in the kidneys: don't store credit card numbers.
It's not just that you have to follow "PCI guidance" (which changes at an average rate of once every 18 months). It's that you become liable for PCI auditing at some unknowable point in the future. PCI audits are not one of our industry's great technical success stories; imagine an IRS audit where the auditor had an upsell interest in making you fail, and you're getting close to the mark.