This is issue one of Insight IOSPIRIT, a series in which I want to give you a peek behind the scenes. Provide more context and color to changes I'm making and present things from a different angle than I'd normally do.
Today, I want to take you on a journey that stretches back over 12 years and that did just culminate in a completely new Online Store for iospirit.com. Also included: an anecdote about running a homebrew credit card processing gateway using a fax modem.
The old Online Store
The old store's cart, originally introduced in 2007.
I experimented with a lot of ideas and different designs when I developed the last IOSPIRIT Online Store in 2007. Back then, however, I was not able to implement the store the way I wanted simply because I found no offerings from the payment industry that would let me process payments the way I wanted to. So I had to adjust the checkout flow to what was available.
Subsequent years brought many changes. E-commerce and tax laws in the EU and Germany required the integration of live VAT ID checks and additional UI. The credit card acquiring bank pushed hard for the integration of Visa's and Mastercard's 3D Secure. And fraudsters tried anything from manipulating the payment amounts in PayPal payment forms to using stolen credit cards.
Big changes to EU VAT laws coming in January 2015
When I learnt about the biggest reform in EU VAT law (PWC, EU) in late February, I was shocked. It will - in a nutshell - require EU-based companies to bill EU customers based on their country of residence and therefore handle 28 different VAT rates, apply the local VAT law of 28 countries and report VAT separately for 28 countries.
I finally had enough.
Looking for alternatives
I started researching alternatives to running everything myself. Full service providers advertise that they will manage stores, purchases, payments and VAT for 8.9% of the revenues. A lot of details weren't clear from their advertising material, though, so I asked them a ton of questions. In the end, thanks to additional chargeback and refund fees not included in the 8.9% as well as the effect of currency conversions for EU-based companies, the full service provider's fees got closer to 11.7% in my model calculation.
11.7% of revenue for a shopping cart that works. Much better than the old store for sure. But I'd have to raise prices, lose almost all control over how the store would look and work - and would maybe never get another shot to make my original plans for a new Online Store a reality.
And then I found out about relatively new payment services and products - established only in the last 12 to 24 months. No monthly fees, low transactions costs and an API that would enable me to finally build that new Online Store.
My 12 year oddysey in the world of credit card acceptance
When I started accepting credit cards in 2002, the idea of e-commerce - let alone shops selling downloads - was still relatively new. Especially to people in finance. In order to gain the ability to accept credit cards at all - let alone for this purpose - you had to go through a humiliating signup process, fill out tons of forms, submit business plans, make estimates and demonstrate a lot of willpower. My negotiation counter part at the bank later told me that it was my persistence, not numbers, that landed me the contract.
If you want to start accepting credit cards through Stripe today, all you have to do is sign up there, fill out a few, simple forms and submit them. And within minutes, you are ready to accept credit cards. What a difference a decade makes!
Gateways that would allow charging credit cards fully electronically were prohibitively expensive for small companies like mine back then. The only thing that was included "free" with a credit card acceptance contract back then was handing in transactions by fax. So I built my own gateway using a fax modem, my own 2D bar code system using my own image creation, analysis and recognition code.
Example of a fax received by my homebrew credit card gateway in 2002
My store's backend would automatically generate faxes with 2D barcodes on them. Credit card charges were listed in a table with four columns: credit card details and the amount to be charged, barcode, field for authorization number, field for decline reason. When the fax was returned - often slightly rotated and with vertical lines all across the page - my homebrew gateway would try to locate the 2D bar codes, decode them and then - based on the 2D bar code's position - determine whether something had been written in the authorization or decline field. Based on which field had something written in it, it determined the outcome of the transaction - and fed the result back into the system.
Eventually prices for gateway usage came down and I replaced my homegrown solution with one of them to speed up processing times and eliminate human error. A few years later, the PCI DSS standard was introduced and essentially prohibited credit card data to pass through the systems of companies that couldn't afford a costly certification. To avoid these costs, I switched to another gateway offering that would allow me to handle credit card payments via a separate payment page and not get in touch at all with credit card data. The main usability problem with that is that customers can only enter their credit card data after they've already submitted their purchase. If the payment fails for any reason, their only option is to enter all data again. Which sucks - big time!
New services like Paymill, Stripe, Braintree and Adyen are now changing the game once again. They are acquirer and gateway operator in one. And by tokenizing credit card data and saving it in a secure, PCI DSS compliant vault for later use, they again enable me to design the checkout flow the way I want while at the same time not getting in touch with credit card data at all.
Coming full circle
The 2015 EU VAT law changes were a huge annoyance when I first learnt about them. And they still are. But they also brought some real issues with the old Online Store back to my immediate attention and made them a top priority. They had me re-assess every part of my business, evaluate full service providers and learn about new, game-changing payment services.
What I decided to do is to transition to Braintree for credit card payments and rewrite the store, taking full advantage of the technological advance since developing the last Online Store. In order to cater for EU VAT law changes, I'll still have to make major changes in many other places, but at least the new Online Store is (mostly) ready for it now. If I can't finish work on the other parts until January 2015, I can use a full service provider as a temporary backup.
The new Online Store
So what's new? Without further ado, here's an overview over some of the improvements the new Online Store brings along.
Minimalistic, flat design
Following the trend towards a more minimalistic, flat design, I got rid of as many pronounced gradients, boxes, lines and form fields as possible. The result looks and feels much cleaner and clearer.
One page checkout
Instead of spreading out the checkout process over multiple pages, customers can now enter their address, choose their method of payment, review and submit their purchase on a single page. The transition between the steps is fully animated and only the form fields for the currently active step are displayed.
Embedded error reporting
If an error occurs, the new store runs a 3D animation on the respective section, mimicing a head shaking in disagreement. It also adds a red glow around the field(s) with errors. When a field gets keyboard focus, a bubble showing the error message for that field is displayed. Once a change was made, the red glow effect disappears.
If an error occurs that would otherwise have gotten its own page with buttons to click on, it is now displayed in a modal dialog, so you can stay on the checkout page. This really improves user experience by several degrees. It also gave me a nice opportunity to (hopefully) impress you with a fancy blurred background "glass" effect (on browsers that support CSS filters).
PayPal Express integration
Finally. I kind of underestimated the degree to which it would simplify the purchase process.
Better fraud management
The store doesn't have access to any more metadata by using PayPal Express and Braintree compared to what was used before. What's new with these is that this data is available before the actual payment has been made. This should really help the fraud score system that's built right into the store to be more precise and produce less false positives. It allows the store to better discern simple mistakes in entering data (and provide help in fixing them) from fraudulent and malicious behaviour.
Automatic estimate showing US Dollar.
Previously the cart contained a dropdown to see what the cart's total value is in another currency. In the new store, the drop down is gone. Instead, an estimate is now shown by default - in the currency of the country the customer has selected. If the exchange rate of the respective currency is not in the store's database, US Dollars are used as a fallback.
While the previous store was based around simple HTML forms, the new checkout page uses a web API and follows the MVC (Model View Controller) development pattern.
I still have a lot of ideas for the store. Adding more payment options and the ability to buy gift certificates for example. But before I touch these, I'll let the dust settle a bit and see how the new store performs. If you notice any glitches, run into problems or have an idea on how to improve it further, I'll be all ears.
What I really like about this project is that it gave me an opportunity to play with the latest web technologies (especially regarding animation) and explore how I could put it to use in a manner that adds value to the user experience and makes the store more fun to use.
Got feedback? I'd love to hear from you via mail (felix [dot] schwarz (at) iospirit [dot] com) or Twitter (@felix_schwarz).