Paypal Sent Me the Mark of the Beast

I’ve had a Paypal premium account for many years now. In fact, I signed up for Paypal when they were so new that if you signed up on a referral you and your friend got $5. I have a premium account because I sell online. One of the features of the Paypal premium account is that you can get a debit card. This debit card can be used to spend your Paypal balance. Recently, they added a bank account as a “back-up fund” for the debit card. I decided to use this feature and occassionally use the Paypal debit card for small purchases.

I’ve had my Paypal debit card for years and I like it. No problems. Sometime in 2007, my Paypal debit card expired. They sent me a new one which I tucked into my wallet. I’ve used it many times but always in person, never online. Boy was I surprised the first time I tried to use it online to create an iTunes account (yeah, I’m a really late adopter here but I’ve been using and loving eMusic
for a long time). When I flipped the card over to enter my security code, I noticed that my card had 666 as the security code. Now those of you that know me are probably laughing pretty hard by now. I looked again to make sure I was reading it right. Yep, 666. So I entered it. And iTunes told me it was an invalid security code.

See apparently, somewhere in the iTunes code a developer decided that rather than spend the few cents to hit a gateway and verify the security code, they’d rule out “obviously” invalid security codes. I’d guess that probably 123, 999 and others would also be flagged. This is a huge design flaw if card issuers actually use numbers like 123, 999 or in my case, 666. Consumers will be unable to buy from those merchants even though they have perfectly legitimate cards. (Of course, the other possibility is that iTunes is correctly designed and that Paypal misprinted my card with the incorrect security code. I kind of doubt that though. I guess I’ll try using it elsewhere online and see).

So what have I learned from this little experience? Two things really. The first is that more care needs to be taken in gathering business requirements when it comes to techniques for stopping fraud. If a requirement states that something is invalid simply because it mimics what people might normally enter as “dummy” data, without a corresponding business rule to never issue data that looks like “dummy” data, that requirement is faulty. The second lesson I learned is that Paypal thinks I’m the antichrist.

Tags: business requirements, credit card security code, itunes, paypal