Give payment processors greater control over the billing form & how they are used

Following on from discussions with Alan, Tim, Dave G the current limitation of allowing off-site processors should apply to paypal standard (which doesn't allow you to enter the credit card linked to an account without logging in) but shouldn't apply to others.

I've started working on this & have made the definition of payment processor capabilities determined by the processor instead of historical processors extrapolated out.

New extendable functions on CRM_Core_Payment are

$processor->supportsBackOffice()
$processor->supportsLiveMode()
$processor->supportsFutureRecurStartDate()

These are intended to be called like

if ($processor->supports('BackOffice'))

{ // sing & dance }

In the course of implementation I found that for the backoffice implementation if you use Realex (the only build in direct debit) the credit card fields (not the debit card fields show). I HAVE addresses this in the code I've got in progress but not the fact that the switching the payment processor doesn't change the fields - too much scope creep.

Additional extendable functions to support fixing this are

$processor->getPaymentFormFields()
$processor->getPaymentFormFieldsMetadata()
$processor->getPaymentTypeLabel()
$processor->getPaymentTypeName()

I also discovered that on one form the function

$processor->getBuildForm()

allows the processor to take complete control of the form (in a quickformy way). I moved this function to a place where it would always be called.

in my code getPaymentFormFields has 2 subfunctions
$processor->getCreditCardFormFields()
$processor->getDebitCardFormFields()

I'm inclined to thing we would encourage people to override getPaymentFormFields rather than the subfunctions (but no strong opinion).

Gaps/ out-of-scope
1) payment_type should be converted to an option group - in a 'if not exists ' kind of a way as I've already had to covert to an option group in the omnipay extension due to dealing with a 3rd payment type

2) I think ideally before getting payment fields we should do either
$processor->setCountry() or
$processor->setContext (or setParams or something)
as the required fields often change by country & potentially by unknown other conditions

3) I guess there is a bigger question about whether sites are happy with the possibility they might not collect some data if the payment processor chooses to unset it from the billing block. At this stage I'm only touching 'paymentFields' but the intent is to do the same with billingDetailsFields (address etc). I'm kind of OK with assuming that processors would only alter these with reason & people deal with that for 4.6. Sites can, of course, set their own profiles to collect these fields and probably my preference would be for the profile fields themselves to be configurable as 'squashers' - ie. this street address field is here on my profile and it should not show in the billing block as well

4) I'm focussed on the backoffice implentation & while this creates a path for other forms to be cleverer about showing fields it doesn't change other form flows. Wierd & wonderful code work-arounds continue to be the order of the day

5) another gap is for payment processors to be able to declare scripts that should be loaded e.g

$processor->getScripts()

& for them to be able to add additional html (e.g an iFrame) - note that at the moment billing tpl looks like
<fieldset>
<fieldset>paymentfields</fieldset>
<fieldset>billingDetailFields</fieldset>
</fieldset>

• so there are 3 potential places that the processor may with to add extra code - the fieldsets are an array that reflects this build so it could be possible for the processor to add an extra fieldset to it & for billing.tpl to take the order from the assigned array of fieldsets