Strict payment validation is now defined somewhat like
Useful when finding available payment methods, for instance, which does not require unimportant things to be a 100% valid.
This definition is very vague, because it does not define "unimportant things" and it leaves the interpretation of "100% valid" up to the reader as well.
I propose we redefine strict validation like this:
The different between strict and loose validation is that loose validation only validates the data that is actually set, while strict validation validates *all* payment data that is required for execution. Example: If Payment::currency_code is NULL, loose validation will not throw any errors (because the currency code is not set). Strict validation will throw an exception, because in order to execute the payment, it needs to know an exact currency code.
Postponed to version 2.
Comments
Comment #1
xano$strict was introduced to support the paymentbilling submodule, but after removing it, the parameter has never been used anywhere else. Perhaps it's a good idea to just remove it.
Comment #2
xanoWe may also want to rename and/or split the validation process, as it's partly validation, partly checking if a payment method can be used with a payment. Calling the latter validation has proven to be confusing to users.
Comment #3
xanoComment #4
xanoThis was removed in #1578020: Convert payment methods to plugins and #2021625: Port payments to content entities.