Yea, the incentives in the wrong place for credit card processors. They actually charge credit processing fees for fraudulent purchases, and then get to charge

Yea, the incentives in the wrong place for credit card processors. They actually charge credit processing fees for fraudulent purchases, and then get to charge processing fees again for the chargeback when the fraud is discovered, even though the merchant sends all the info they have to the processor and the processor okays the transaction. The credit card processors have the most information, but the least incentive to fight fraud. At LimeWire, for a while, the price for LimeWire Pro was a hidden field in the order form, because the CTO (rightly) wanted to minimize the amount of logic running on anything that touched credit cards. The form was generated on one host and posted to another, and the logic for experimenting with lower prices at certain times, etc. was kept off of the host that processed credit cards. As a result, some more technical users could order LimeWire Pro for $1. But, they could also find LimeWire Pro using the free version, so no real loss there. However, some carding gangs also noticed, and would validate huge batches of credit card numbers by buying LimeWire Pro for $1. The cargebacks were a bit painful, but more importantly, if your fraud rate is above some threshold, your fees go up, and at some point our credit card processor gave us 2 months to bring down our fraud rate or they'd cancel our merchant account. The processor also refused to give us fraud information updates with any finer granularity than monthly, so we basically had two tries to bring the fraud rate down. All of the existing CAPTCHA systems I could find required a shared filesystem between the process generating the CAPTCHAs and the process checking the answers. That was a no-go with our policy of minimizing attack surface of our credit card processing host. So, I wrote a CAPTCHA that used HMAC to generate a 96-bit tag from a timestamp (at 1 minute granularity), the user's IPv4/24, and the price. The other 64 bits of SHA1-HMAC output were used to seed the prng that generated the CAPTCHA. The timestamp and 96-bit tag became hidden fields in the HTML purchase form. That way, the credit card processing box could validate the time, IP address, and price, and check the CAPTCHA answer, all from the submitted form data. Answers with timestamps more than 20 minutes old were rejected, so the processing box only needed to remember all of the correct CAPTCHA answers over the past 20 minutes to avoid replay attacks. Making the timestamp 1-minute granularity prevented bots from hammering the system until they got easy CAPTCHAs. The first day we put my CAPTCHA system in production, we saw an IP in Virginia very rapidly trying to make purchases without the CAPTCHA. Then it paused for a few minutes while the attacker figured out what was going on and manually solved one CAPTCHA. Then a rapid-fire batch of purchases came through with the same CAPTCHA answer, and only the first purchase came through. A couple minutes later, that exact same CAPTCHA 96-bit tag and answer came in from a UK IP address, but it was rejected because the 96-bit tag didn't match the HMAC. Those were fun days, but it's a shame incentives are so misaligned.