So, an automated renewal failed because I didn't have enough money in my account.
I moved money and went to the payment section website to ask for payment to be taken, but there was no option to do so.
Lesson 1: If you provide autorenewal as an option, and don't provide the ability to "try again", you haven't yet finished implementing this feature.
I then added a backup payment method to see if it would take it automatically. It did.
So that was well implemented, yes?
Well, no, not really: I added the same card again.
Lesson 2: If you're going to validate payment details, validate them. That doesn't just mean checking the card is valid, it means checking your overall payment model makes sense. Your backup and primary should not be identical.
@kevlin I would actually argue against that. Having primary and backup payment methods be different should perhaps occasion a warning, but if there's no mechanical reason against it, I don't think the computer should tell humans no.
Consider the opposite case: It sounds weird, but I have good reason to do this, but the computer says no.
I also don't want more logic with an override, that way lies madness.
@aes @kevlin words have meaning, systems have an architecture, and i don’t thing software nihilism is a good choice. Particularly for a payment system. A primary and a redundant backup absolutely should be different.
This is almost as odd as saying “I think i should be able to enter a *different* passwd when establishing one and the system wants to confirm my first entry.”
@BenjaminHimes @kevlin I can easily see how "try twice" might be used as a (bad) security measure, or something equally nutty. It's not nihilistic, it's limiting the system to a simpler model.
I agree that 'primary' and 'backup' might not be the best naming here, I'd much rather have the simple word 'list'.
Kevlin Henney
aes
BenjaminHimes
Milan Todorov