Validation for different payment methods is pretty well buried on the other side of the gateway object from the form's perspective. We would like to move these processes somewhere closer to the form classes, but in a place that the gateway adapter can still use the same functions in the DataValidator to make sure transactions we are about to make, are in fact sane and valid before we get the bad news from a wasted API Call to a 3rd party.

One problem we definitely have, is that there is currently no mechanism at the gateway level to define required fields for individual payment methods.
Another problem we have, is that the mechanism at the form level which controls what's optional vs required (100% our call if it's not made explicit by the gateway), is all over the place and nearly impossible to find and work with.

When this is done, it should be easy to discover and alter what fields are a hard requirement by the gateway, what behaviors are our UI choices, and where the corresponding translated error message is meant to land on the form.
Ideally, this task wouldn't be done independently of the one that covers the frontend validation cleanup. At the very least, both should use the DataValidator class where possible.