Gift Cards Getting Declined?

Several months back, I was testing an application’s ability to charge credit cards before going live with it. The application allowed people to make one-time purchases, purchases using a previously saved credit card, and subscription purchases wherein people’s credit card information was saved for future use. Like many sites, we used a third party to charge and store the credit card information securely. (In our case we used Authorize.Net Customer Information Manager–also known as CIM.)

As a part of my testing, I employed the use of VISA, MasterCard, and American Express gift cards to make sure they worked too. We didn’t want to miss-out on any potential purchases. However, we ran into a curious situation when using gift cards as saved cards: the first transaction would be approved but any subsequent attempts would always be declined.

I spent the majority of a day talking with our merchant gateway (Authorize.Net), our payment processor, and the gift card issuing banks to try to understand what in the world was going on. Just like any perfectly-executed Department of Defense project, not one person knew or could explain the big picture. Each person could only tell me what they knew about my declined test transactions and point fingers at someone else. After speaking with everyone, though, I was able to extract what was going on.

To make a transaction with a credit card online or in the real world, you must provide a piece of verifying information. There are two options: (1) the 3-digit security code on the back of the card or (2) your physical address.

The catch about using your physical address for a gift card purchase is that you must first register the gift card with the issuing bank so that they have your address on file to verify it. The problem with address verification is that virtually no one registers their gift cards. (I didn’t even know it was possible.)

The problem with security codes is that no one other than the issuing bank is allowed to store it. The merchant gateway might capture and send along the code when making the initial purchase and even storing the card. However, it will never be available for subsequent transactions. This is why our gift cards were being declined when used as saved credit cards. We were sending the customer’s address to the payment gateway, but the issuing bank didn’t have an address on file to verify. And we couldn’t send the security code because Authorize.Net hadn’t stored it.

So, what could be done? Well, we couldn’t just reject gift cards on our site because there is no way to determine if the card is a credit card or gift card. (The only people who know this information is the card holder and the issuing bank. Credit card processors and banks are agnostic.) We could require the customer to provide a security code on every saved credit card transaction or subscription transaction, but that inconvenience to all of our customers would defeat the purpose of storing credit cards for automatic processing. The only viable option was to tell customers to register their gift cards with their issuing bank if they wish to use a gift card as a saved card or for subscriptions.

Hindsight is 20/20, so this makes perfect sense. However, it was quite confusing before the epiphany. Hopefully this will save some others a day of investigation.

Rails path and url helpers

Sometimes I forget the simple differences between Rail’s helpers. This mini post is so I don’t forget.

*_path
Generates relative URLs: /users
Used in views by link_to, form_for, etc. (per DHH)
The browser maps relative URLs to absolute URLs based on the current page’s protocol and host (/users on the page http://domain.com/new translates to http://domain.com/users)

*_url
Generates absolute URLs: http://domain.com/users
Used in controllers by redirect_to (per DHH) because RFC 2616 states that redirects must be absolute URLS. This is true, however, modern browsers can handle relative URL redirects now too

Testing Rails Exception Notification in Production

Every Ruby on Rails project I have been involved in has used the Exception Notification gem. It sends you an email with very helpful debugging information whenever your application breaks in the real world. However, I’ve seen people fail to ensure that it actually works in their production environments–not when they first launch their site, but weeks and months afterward when it really matters. If your production environment changes, your application may fail, but you might not get an email about it because that which broke might have affected email sending. And you’ll think everything is honky-dory. Make sure you have something like this in your application and that you test it periodically to ensure you’re getting exception notification emails.

In config/routes.rb:

  map.connect 'test_exception_notifier', :controller => 'application', :action => 'test_exception_notifier'

In app/controllers/application_controller.rb:

  def test_exception_notifier
    raise 'This is a test. This is only a test.'
  end

I also recommend adding this to a periodic test script and your deploy script so you don’t have to remember to test it.

The Unplugged by Ruven Meulenberg

While researching user experience design techniques, I stumbled upon some nifty whiteboard magnets for prototyping called GuiMags as well as a complementing book called The Unplugged.

GuiMags look like the nicest way to prototype something before going to HTML and CSS. Labor intensive forms of prototyping don’t seem to add much value, and paper and traditional whiteboard prototyping only works until you’ve changed your mind about something and have to throw your work in the trash or erase half the board.

Although I decided to postpone a magnet purchase until I am doing design again, I was able to get my hands on the book. Its premise: we limit ourselves by the technologies we use. Instead of thinking outside the box, we’re often thinking and functioning in it. A large part of this thinking inside the box is how we develop software.

Although, everyone interested in the topic should pick up the book, here are a few of my takeaways:

Every major form of art that involves technology (music, film, video games, graphic design) starts outside technology. Artists do not limit themselves by their technology but by the limits of their own minds. As a software engineer, you often limit yourself by the technology you use day-to-day.
Spend as much time as you can iterating on concept and design before going to implementation.
Design the software front-end not the back-end first.
Just like there are code freezes, freeze the product when it has passed the design phase.
It is often wise to outsource the implementation.
- This serves as a peer review of the design before it goes to implementation. Software developers traditionally think about the back-end first.
- Different cultures have different strengths: “England and Western Europe are great at design, Ukraine and Macedonia have amazing and prompt developers who can think for themselves, the Netherlands always emails back the same day, India is extremely polite, etc.”
- Work can be done while you are sleeping. “This can cut the development time in half.”
- Because you already know what you want and won’t be constantly changing the design, contractors will want to work with you even if you pay less.
- Only be satisfied with five-star developers.
- Pay more than you agree to pay.
- Do one-week sprints. Longer sprints end up getting delayed, with excuses.

With the last (sub)point in mind, I think this methodology is well-suited for an agile development process.

There is a lot to gain from reading the book, so make sure to grab a copy for yourself.

Catching Up to Video Games

A little over a month ago, Yahoo’s Douglas Crawford gave a great presentation on “The State of Ajax.” His opening was brilliant. He started with a brief history of computing ending with some of the incredible things being done in the video game industry, including current real-time 3D rendering of hair, light, reflections, and the like. Then he pokes fun at the web development community because of their excitement over rounded div corners. Clearly, we have some catching up to do.

Although I have been opposed to the use of Flash for regular web sites for years, Office Max came out with a nifty Flash application last Christmas called “Elf Yourself,” which they’ve upgraded this year. Not only can you skin the dancing elf with your own face, you can call a 888 number to record your own message to viewers. Very clever and very funny. Take a look at what my little brother, Nate, pieced together and then elf yourself.