Backend DirectDebit Support?

[adixon]

I'm trying to enable a 'backend' direct debit option for my new payment processor.

For the 'front end', i've used the built in code that I discovered that doesn't seem to have any documentation -- i.e. by setting the 'payment_type' field of the corresponding entry of the payment_processor_type table. That does some magic stuff to pull up Direct Debit fields when using that payment processor (instead of credit card fields).

But the 'back end' payment page uses a different piece of code, someone opaquely. Starting here:

CRM/Contribute/Page/Tab.php

in the edit function, there's some code that invokes code in here:

CRM/Contribute/Form/Contribution.php

which seems to have been modified to support DirectDebit, but it doesn't work. That is, even if you choose a Direct Debit payment processor, you get the credit card fields.

The Tab.php page is pulling in a bunch of stuff using AJAX, and the relevant url seems to be this one:

/civicrm/contact/view/contribution?snippet=4&formType=CreditCard&mode=live

i.e. this is what's pulling the credit card fields into the backend contribution form. When I replace CreditCard with DirectDebit, I don't get the Direct Debit fields, however, and in any case, this url isn't being invoked by the Tab.php code.

Conclusion:

I think there are three things still to do before we've got a backend DirectDebit option.

1. Some label issues (the links and pages currently just say Credit Card Contribution).
2. The backend contribution page needs to pay attention to the selected payment processor 'payment_type' in order to correctly invoke the right ajax.
3. The ajax callback with DirectDebit needs to work (the code appears to be in CRM/Contribute/Form/Contribution/Main.php)

Can anyone confirm this is the right direction and/or if some work has already been done along these lines?

Xavier - have you explored this with your SEPA code?

[xavier]

Yes, and indeed, full of magic

at the end, the workaround I found was to use the same workflow for front and back office: if you add cid=0 as a param: it forces to ignore the logged in user.

and voila, if I recall, we have a simplified contribution page we only use for back office user (with a slightly simplified form), added it in the navigation menu and good enough for our need.
X+

[Eileen]

For clarity cid=0 as a param works on event pages from way back & contribution pages from 4.4 onwards.

From 4.4 onwards they both allow you to select the contact you are filling it in for (if you have appropriate permissions)

[SarahG (FountainTribe)]

I tried the URL with cid=0

ie http://www.mygroup.org/civicrm/contribute/transact?reset=1&id=3&cid=0

It shows me the correct contribution form, with all fields being empty. But there is no method for me to select an existing contact. (I could fill in their name, email, etc. but this seems error prone and confusing for a staff member to use for an existing contact)

[SarahG (FountainTribe)]

Also You may want to look at the code for the project: https://drupal.org/project/vanco_payment This is a payment processor for Vanco which also offers ACH within CiviCRM

[xavier]

Check out eileen comment, you need to upgrade your install to get all the latest goodies (not to mention potential security issues)

X+

[SarahG (FountainTribe)]

I am having the issue on version 4.4.4.  Is this recent enough?

[Eileen]

I tried the URL with cid=0

ie http://www.mygroup.org/civicrm/contribute/transact?reset=1&id=3&cid=0

It shows me the correct contribution form, with all fields being empty. But there is no method for me to select an existing contact. (I could fill in their name, email, etc. but this seems error prone and confusing for a staff member to use for an existing contact)

The form will only show if the person has the ability to view at least one other contact in CiviCRM - but I think you are saying they have that - here is what is looks like on demo

http://drupal.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1&cid=0

I think that is it - here is the code block that adds it

Code: [Select]

  /**
   * add autoselector field -if user has permission to view contacts
   * If adding this to a form you also need to add to the tpl e.g
   *
   * {if !empty($selectable)}
   * <div class="crm-summary-row">
   *   <div class="crm-label">{$form.select_contact.label}</div>
   *   <div class="crm-content">
   *     {$form.select_contact.html}
   *   </div>
   * </div>
   * {/if}
   * @param array $profiles ids of profiles that are on the form (to be autofilled)
   * @param array $field metadata of field to use as selector including
   *  - name_field
   *  - id_field
   *  - url (for ajax lookup)
   *
   *  @todo add data attributes so we can deal with multiple instances on a form
   */
  function addAutoSelector($profiles = array(), $autoCompleteField = array()) {
    $autoCompleteField = array_merge(array(
        'name_field' => 'select_contact',
        'id_field' => 'select_contact_id',
        'field_text' => ts('Select Contact'),
        'show_hide' => TRUE,
        'show_text' => ts('to select someone already in our database.'),
        'hide_text' => ts('to clear this person\'s information, and fill the form in for someone else'),
        'url' => array('civicrm/ajax/rest', 'className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1'),
        'max' => civicrm_api3('setting', 'getvalue', array(
        'name' => 'search_autocomplete_count',
        'group' => 'Search Preferences',
        ))
      ), $autoCompleteField);

    if(0 < (civicrm_api3('contact', 'getcount', array('check_permissions' => 1)))) {
      $this->addElement('text', $autoCompleteField['name_field'] , $autoCompleteField['field_text']);
      $this->addElement('hidden',  $autoCompleteField['id_field'], '', array('id' => $autoCompleteField['id_field']));
      $this->assign('selectable', $autoCompleteField['id_field']);

      CRM_Core_Resources::singleton()->addScriptFile('civicrm', 'js/AutoComplete.js')
      ->addSetting(array(
      'form' => array('autocompletes' => $autoCompleteField),
      'ids' => array('profile' => $profiles),
      ));
    }
  }

[adixon]

Thanks all for your helpful notes.

I'll give it a shot ...

[adixon]

Here's where this ended up:

1. Any enabled payment processor that uses a payment processor type that has 'payment type' = 2 breaks back-end credit card processing (i.e. even for other payment processors site). 'payment type' = 2 is the not-well-documented way to identify a payment processor type as ACH/EFT (direct debit).

It 'breaks' it by hiding the credit card fields and replacing it with a Direct Debit header.

For now, I wrote a form hook to remove my ACH/EFT payment processors from the list of available ones on that back-end page, and it fixes it, but that's a core bug that's probably easy to fix.

2. While I was in there, I also generated a list of payment pages that use my ACH/EFT payment processors and provide the user with direct links to add contributions for that user (i.e. not cid=0, but cid=<the contact being edited>

My method for attaching those urls into the page is a bit ugly, but at least it provides some kind of backend functionality, and prevents the payment processor from wrecking the backend credit card form. This seems better than linking to a page with cid=0 and requiring the administrator to re-enter the contact's name.

3. For the future, a new button that goes to a new dedicated backend ACH/EFT/direct debit contribution page sounds like the right way forward.

[adixon]

Issue filed here: https://issues.civicrm.org/jira/browse/CRM-14442

Patch in progress.

[adixon]

Patch provided on that issue that applies to 4.3 - 4.5.

[magnolia61]

I just opened a new topic that touched the subject of backend Direct Debit handling. Please have a look if you want to.
http://forum.civicrm.org/index.php/topic,36408.0.html