>I know, I know, avoid if at all possible and use something like Authorize.NET.
>
>I'm being asked to store CC info in our DBs to perform recurring billing. "We're compliant" has been said and I've been told to use our broken encryption libraries to encrypt it. I need some info to throw back. Links to laws (state of Iowa), etc.

This is usually available through whoever is actually doing the processing. A lot of vendors support recurring charges through their API, or have a "token" you can request and use for charges instead (the idea being you pass the CC info, they give you back a token that is safe to store; on subsequent charges you pass the token instead). PCI compliance is more of a contractual thing (not a law). No storing of CVV2/CID #s/PIN or PIN block, no storing of the raw CC swipe, data must be kept encrypted, removing the data when it's no longer needed, etc.

The biggest "selling" point to businesses to not try to do this themselves is the penalty (in $) in a data breach. Their agreement with the CC processor probably includes a lot of language around this.

But if you can't convince them, at least use a real encryption library (esp. since you're describing your current one as "broken") and follow the rules I listed above. Those are at least things you have some control over as a developer.