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.
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.
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?
So here are some cribbed criteria for a beautiful program might be:
Instead, I'll have to borrow from the slightly-less-complex-but-still-intractable problem of what beautiful math is.
First, this raises the question, what is a "beautiful" API?
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.