What I learned writing payment interfaces (Part I)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

When I think about what I've learned writing payment interfaces, I might have started our quest with a discussion of industry terms and how they’re used, or how we need to use A/B testing to measure user response to changes and monitoring the shift in conversion^[1] in basis points^[2], or the impact that acquisition^[3] has on payment - these are important topics, especially to people who write payment interfaces - however, the most important topic we need to understand is the payment business, and the most important things we need to understand about the payment business is that speed matters and velocity matters. To understand speed, we’ll start our questioning at the beginning.

Foundational Questions

• What’s the average worldwide DNS lookup time? Which is faster IPv4 or IPv6?
• What load balancing device is used for external load balancing?
• Who are NACHA and OFAC?

These questions, at first glance, don’t really appear to be questions User Interface Engineers consider. That first question – DNS lookup time – a UI engineer doesn't control that. It's the same with the load balancing device. Don’t those belong to “operations”? NACHA and OFAC? Those are business groups, right? Why are these important?

As I've already stated, speed is important – in fact, it’s one of the most important considerations during checkout. However, not all site speed issues are directly related to things UIEs have under their control. The reality is that speed cannot be considered in isolation, however, speed cannot be an afterthought either. We must be aware of just how the factors outside of our control affect speed, in part to take steps – like minimizing DNS lookups – lookups that take 400ms on average^[4] – to increase speed, and in part to know what actions will have greater, or more immediate impact. For example, would it be better to keep an IPv4 address or use an IPv6^[5] and change the load balancing algorithm? What impact would a change to from a consortium bring forward, for example, what if the rules OFAC uses to restrict payments changed or if NACHA changed constraints regarding required information? Are any changes to the foundational elements large enough to affect overall speed?

It is without question that these foundational elements affect speed. It is also without question that is largely a balancing act of almost innumerable variables where we're hopefully reducing the cost of some of the variables so that we might offset increases in the cost of others. To maintain this balancing act, we must learn to step outside of our typical domains to understand, and at times to help others understand, the foundation upon which our app is built and specifically how it relates to speed.

Notes:

1. Conversion is the percentage of users who actually pay once the transaction has been started. Think of it as a queue of people waiting to pay - those that actually do "convert" and those who decide they're too busy or have forgotten their wallet "abandon" their transaction, and the rate is abandonment.
2. A basis point is one one-hundredth of one percent (.01%), or one more paying customer out of a queue of 10,000 people.
3. Acquisition is converting a guest user to a member user. Data clearly demonstrates that forced acquisition - forcing a customer to create a username and password to complete a purchase - lowers conversion significantly (which is not to say that the cost incurred by the reduction in conversion would not be offset by benefits of acquiring new members).
4. The 300-400ms speed reported by Google is considerably faster than the 400-800ms speed reported at Velocity 2010, however, it's still significant. For further reading, I'd recommend A Dismal Guide to DNS and the Performance Benefits portion of the Public DNS discussion on Google Developers. If you'd like to run a simple test to see how long a DNS lookup might take for one of your users for your domain, you can check http://www.dnswatch.info/dns/dnslookup?la=en&host=insert-your-host-name-here&type=A&submit=Resolve - just replace the insert-your-host-name-here with the host name you want to check (e.g. cathmhaol.com).
5. You can see Cisco's data regarding IPv4 vs IPv6 at http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf, of course you'll also want to take a look at An Engineer's Guide to Bandwidth to help make sense of the information presented by Cisco.