What I learned from writing payment interfaces (Part III)

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

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we'll start our exploration of velocity^[1].

Risk Mitigation

• What do we know about the product that might affect the transaction?
• What do we know about the customer that might affect the transaction?
• What can we learn about the customer while they’re making their payment?

As anyone who has written apps for any length of time can point out, there is more than just raw speed that we must consider. In another post, I've referred to this something similar as completion time, likening it to load time and render time; however, in this series I'll use the term velocity to refer to how quickly the user moves through a process.

One of the major factors affecting velocity in a payment interface is risk. Processor declines, charge backs, and disputes can easily derail an otherwise profitable business; however, the rules defining risk, such as "selling jewelry is riskier than selling shoes" or "new customers are riskier than existing customers" typically exist outside of the payment interface^[2]. Of course there is risk associated with all sorts of transactions, such as legal ramifications brought about by not attending to country-specific restrictions. Ideally, there is a secondary process (hopefully isolated) that tells us whether the customer we think we have is really the customer we have.

In a payment interface, and in an app, we don’t generally need to be concerned at a high level that our risk rules fail to block the right transaction (e.g. a shipment of alcohol to a restricted locale) or alternatively, exclude otherwise valid transactions (e.g. a person preparing for a trip by purchasing electronics such as digital cameras along with prepaid phone cards). In our app our task is to collect enough of the right information in order to make reasonable decisions regarding not only how much risk is associated with a specific transaction but also about how much risk we are willing to allow.

More importantly, of course, we have to be cognizant of whether or not while we are collecting the right information we are negatively impacting velocity. One typical bottleneck we've seen is in the collection of an address. Of course this is in part due to the difficulty of gathering addresses in a global setting (which we'll touch on in Part IV) but also due to difficulties with regard to validation of an address^[3]. Not only is there a significant chance that we will affect user velocity with our risk rules, there is a significant chance our risk rules themselves prove to be a problem. That does not mean we should eliminate the risk rules, simply that those rules should be integrated into app code with the utmost care, and, of course, testing.

Notes:

1. Velocity, unlike speed, is a vector measurement - it's related to movement in a direction.
2. There are risk factors that are especially applicable in developing payment interfaces - things like product type (e.g. prepaid cards, jewelry, electronics) and the country of the buyer and seller; however, there are also more general risk factors we can attend to, such as a mismatch between the originating location of the request and the user-reported location or a user accessing an account that has a negative history (how 'negative history' is defined is less meaningful - it could mean anything from a poor reputation score to chargebacks).
3. For further information, you may want to read my post regarding Address validation.