Payment Systems & Beauty

I was prompted to consider this question by a tweet by Ted Dziuba:

How important is a "beautiful" API, especially in payments?

Due to my experiences (in a previous life) having investigated many payment APIs, and been deeply disappointed by all of them, I have some ideas about it.

First, this raises the question, what is a "beautiful" API?

That question is so complex that there is an entire book called "Beautiful Code" that doesn't actually say what beautiful code is.

Instead, I'll have to borrow from the slightly-less-complex-but-still-intractable problem of what beautiful math is.

So here are some cribbed criteria for a beautiful program might be:

• A (program) that uses a minimum of additional assumptions or previous results.
• A (program) that is unusually succinct.
• A (program) that derives a result in a surprising way (e.g., from an apparently unrelated (library) or (protocol).)
• A (program) that is based on new and original insights.
• A (program) that can be easily generalized to solve a family of similar problems.

Is it important for a payments API to have a minimum number of assumptions or rely on "previous results", i.e. inputs from its user?

I think the answer to this is pretty clearly "yes". Each assumption or input that your payments API has to rely upon is a new potential failure mode, which may result in defects, which in turn result in errors in payment processing.

I should also probably stipulate that defects in a payment processor and errors in payment are a serious problem, and therefore it is important to avoid them. Sufficiently bad problems can lose you money, or cause you to steal money from your customers, or enable someone else to steal money from them, which can (at least hypothetically) land you in jail.