Indeed, the payment tagging scheme is a mix of generic and specific values. You can say payment:credit_cards=yes, but you can also say payment:visa=yes payment:mastercard=yes payment:discover=no payment:unionpay=no. Similarly, electronic tolling accounts and transit fare cards can be specified in more detail. This is good because users don’t want to find out at the last minute that they just barely lack a compatible payment method. If a user has gone through the trouble of looking at the logos on the door and tagging the specific payment methods, we should try to preserve that work.
Iterative refinement might be a good idea, specifically to avoid freeform keys. But payment:cards=[freeform value] cannot coexist with the existing payment:cards=yes/no. It would have to be something like payment:cards:brand=*. At that point, we might as well add payment:cards:brand:wikidata=*, or just payment:wikidata=* (with multiple values separated by semicolons). This way, a data consumer can look up all the names and icons they need from Wikidata, instead of maintaining their own incomplete lookup tables.
The University of Kentucky’s Plus card is a student ID card (campus card) that doubles as a debit card. I see you’ve already raised this issue on the one business tagged as accepting this kind of card. Given that it’s an on-campus eatery, I think this tag most likely refers to the university’s student meal plan. The Plus card is accepted at some off-campus eateries, and there’s another university campus just a few minutes away, so maybe it makes sense to be specific to avoid user confusion.