I thought about that, but I think it’s actually more error prone, because people might just be setting ?amount=32 and leaving out currency which might lead to unexpected behaviour. Implementors tend to interpret this differently and one app might take the default currency and the other might fail to accept it, and that kind of different behaviour is a common source of security issues. Having a single unified parameter that must always contain the value and currency “solves” that issue.
Makes it a bit more annoying to parse, though I definitely see your point.
However, you’re still proposing a standard: “has to include both the currency and the amount in the parameter”, so why not split them up at that point?
I thought about that, but I think it’s actually more error prone, because people might just be setting
?amount=32and leaving outcurrencywhich might lead to unexpected behaviour. Implementors tend to interpret this differently and one app might take the default currency and the other might fail to accept it, and that kind of different behaviour is a common source of security issues. Having a single unified parameter that must always contain the value and currency “solves” that issue.Makes it a bit more annoying to parse, though I definitely see your point.
However, you’re still proposing a standard: “has to include both the currency and the amount in the parameter”, so why not split them up at that point?