WildCard Systems

In 2005, eFunds acquired WildCard Systems. In 2007, Fidelity National Information Systems (now just FIS) acquired eFunds.

I spent about five years at WildCard, and I wanted to elaborate a bit on what I did there, beyond the normal constraints of the résumé format. Thankfully, this is the web, and I can get away with it.

WildCard acquired AMG in January 2000 in order to supplement their in-house web talent. WildCard’s business is stored value card programs; gift cards, payroll cards, insurance claim cards, etc. Divide electronic payments into three groups: pay later (credit cards), pay now (debit cards), and pay in advance (stored value). WildCard sells a client a stored value card program, and part of that program—the part I was involved with—is a web site where cardholders can access account information, and future cardholders can purchase cards.

AMG was a small company, but as part of WildCard we started to grow quickly. In the summer of 2000 we built the Visa Buxx web site, but the look of the site was provided to us by an outside design firm. AMG had a Linux/Apache/MySQL/Perl background; WildCard was a Microsoft shop and used Windows, IIS, and MS SQL. Reluctant to simply adopt IIS and ASP, we evaluated several web publishing platforms and environments for the Visa Buxx project, and ultimately selected ColdFusion with Spectra running on Windows/IIS. We didn’t know ColdFusion, so we had experts come in and train us. We built Visa Buxx, designed from the start to be brandable for different bank clients, and limited configurability.

Over the next several months, a few other big, brandable sites were developed, and our small team—half a dozen web developers—began to see patterns emerging, repetitive coding that was simply begging for abstraction. To address this, we built a much more general, extensible system that could handle not just one brandable template, but many. By this time we had abandoned Spectra as not meeting our needs, and our homebrew system ran about two dozen sites within a year.

As a first attempt at a generalized web publishing system, it wasn’t bad, but it had some limitations that, after a while, started to become liabilities. Two developers (of which I was one) then stepped aside from day-to-day site building and consciously designed our next web publishing engine, looking at all the things we were doing repetitively, but also looking at the direction WildCard’s business was headed and how we would need to structure the system to accomodate the business plan. We built the new core, and then built a few sites on it; we refined and extended the core, and built more sites. After four years, the system was running over two hundred web sites, created by developers in three different facilities (Maitland, Ft. Lauderdale, and India), running on a dozen separate servers.

This new web core worked by organizing sites and site templates into a hierarchy; typically a root level, basic language content, a B2B or consumer grouping, template class, client grouping, and web site. We could attach programming, layout rules, configuration parameters, text, or artwork at any of these levels, using an OO-like inheritance model. We also optimized the system for performance, preferring to precache data in memory and reference it from there whenever possible. We structured our databases so that site configuration and content data (which does not change while the site is running) would never require data to be overwritten, only new data inserted with an updated timestamp. This made rolling back changes, when necessary, very easy.

With such a complex system, we needed to build tools as well. Initially started as convenience items for the six developers building web sites, they grew into applications in their own right. These tools ran under the same core, although when necessary they would work “under the hood” in ways that normal sites within the system could not.

Creating this system wasn’t just an intellectual exercise. By abstracting out many of the areas that new web programmers have difficulty with—data validation, database access, session management, effective code sharing, separation of code from content, and others—we enhanced the security and reliability of our entire system, while at the same time reducing the amount of time needed to produce slightly customized versions of web sites. (That’s one thing I learned—there are always customizations.) Building this was a good infrastructure investment on WildCard’s part, and it paid off for them.

All of this was back in the early 2000s. Today, web frameworks are not cutting-edge, they’re essential parts of the development process. But looking back at the work we did we can see that we picked many (not all) of the same solutions the web industry has settled on for best practices.

Photo Credits: some card projects I worked on: Damien Jones