A Taxonomy of Payment Methods
A way to classify payments that shows why there's so much confusion around what payments are
When you pay for a coffee with a credit card, the amount of money that moves as a result is zero.
A lot of people seem surprised that everything stays the same when you tap that piece of plastic onto that tiny machine. Somehow, both you and the barista are persuaded that it is now OK that you get your coffee, because money has “changed hands”. But that isn’t what happened.
Payments are not about moving money, but keeping things moving.
The idea that payments are only tangentially related to money has been in my mind since I read Patrick McKenzie’s definition of what a payment is:
Stripped to its fundamentals: a payment is a message, with new information, about a debt, with a certain confidence level associated with it.
— Patrick McKenzie, Bank transfers as a payment method
This definition is shocking, and also incredibly accurate. But it’s not very helpful. Payments are messages, yes. But there is nothing that engineers can do with that piece of information, and certainly they aren’t better equipped to build payment applications once they hear it.
I believe that a more useful definition is this: a Payment is a Promise Made by An Authorized Party about a Transfer.
This definition highlights why many quite don’t get what payments really are. There are dozens of dimensions by which you could categorize payment methods. But the two most important ones have to do with concepts that belong to computer science: promises, and identity/access management.
It is also a definition we can build a taxonomy around.
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Recently, we’ve looked at the engineering mindset behind checks, how to build a language around payments that other people can understand, and the $100 million, payment-based opportunity that few marketplaces are taking advantage of. They’re all free to read.
Want to be notified when there’s a new post? You know what you have to do.
Payments are promises, and that means that they are constructs that you treat as a “result that will be available”. Payments being promises reflects the risk associated with time that is inherent to all money exchanges.
“A bird in the hand is worth two in the bush” and all that.
In payments, time risk means that, sometimes, confirmation may take a while, so that someone in the back-office can double check that everything is fine.
But bigger than time risk for payments is fraud: someone who isn’t supposed to be able to pay finds a way to do it anyway. For that reason, payments have a built in mechanism that must mitigate fraud risk.
Every system online has a protocol like that, to manage the identity and the permissions of their users. It’s a way to verify that they are who they claim to be (authentication) and that are allowed to do what they are trying to (authorization).
Just like users have passwords and confirmation emails, so do payment methods have a predefined set of actions that customers may have to do in order to verify their identity.
Therefore, all payment methods fall into four “boxes”, according to these two dimensions.
Finalize Now, No Customer Action
Cards are the only payment method in the top left quadrant: they finalize immediately and don’t require customer action to complete. This echoes what I talked about on Advice I Wish I Had Known When I Built My First Payment Application: that card payments are a specific, narrow use case that’s unique and isolated from the rest.
So often, payment application projects fail, and the number one reason is this: they are built on top of abstractions designed for cards, which aren’t great at representing other payment methods.
Finalize Now, Requires Customer Action
Cards may also fall here when there is a 3DS Challenge requested to the user. This quadrant includes most of the payment methods that have been implemented by private companies, like Google Pay, Apple Pay and Paypal.
In order to authorize a payment, the customer needs to provide additional information, usually in the form of a One Time Password, or by tapping a confirmation button on a third party app.
Google Pay and Apple Pay could be in the No Customer Action, to the extent that they don’t always have to go through a 3DS Challenge. Yet, these pass-through wallets require a previous setup on the user’s phone.
Finalize Later, No Customer Action
The cheapest ways to pay are the ones that take the longest, because these payments are subsidized by the bank’s ability to earn interest on the payment amount while the money is in transit.
ACH, SEPA and direct debit are bank-driven, almost free payment methods that sit on top of bank transfers.
Paypal, in the early days, used ACH in the background to reduce payment costs, in combination with a credit card that acted as a fallback.
Finalize Later, Requires Customer Action
And finally, Bitcoin and checks represent payment methods that are either too old or trust-less. These payment methods require a high amount of verification to support, which takes time and demands a little bit of effort from the customer.
Separating the Generic From the Specific
So that’s my taxonomy. I have no formal evidence for it. But I believe that all payment methods, existing and not, always fall into one of these categories.
This alleviates a lot of pressure from the design of payment applications. If that is true, engineers can build software in such a way that the specifics of a payment method can be flexible by making the generics more rigid.
If the generics of payment methods are invariant, these two dimensions can become the scaffolding on which to build the particulars of each payment method, independent of each other.
That could save a lot of time and headaches.
When we are certain that generics will change very little, we can leverage that to build specifics that are easy to plug and play. Generics become boring, and specifics become daring.
It helps the startup go faster.