donordepot / com.donordepot.authnetecheck Goto Github PK

Since an admin can process a credit card transaction on the backend, it seems only natural that they'd also be able to process an ACH transaction.

When processing a back-office trasaction, I get the following error:

Notice: Array to string conversion in CRM_Utils_Address::format() (line 208 of civicrm/CRM/Utils/Address.php).

AFAICT, it looks like an either/or proposition: If you use eCheck, you can't use Authorize.net for credit cards and vice versa. If you try setting up eCheck as a separate payment processor using the same credentials, it replaces the existing Authorize.net payment processor and there's no option for cc# entry on the form.

Am I missing something? Any feedback greatly appreciated… thanks!

When processing a back-office trasaction, I get the following error:

Notice: Undefined property: CRM_Core_Config::$defaultContactStateProvince in CRM_Contribute_Form_Contribution->setDefaultValues() (line 504 of civicrm/CRM/Contribute/Form/Contribution.php).

When processing a back-office trasaction, I get the following error:

Notice: Undefined property: CRM_Contribute_Form_Contribution::$_lineItem in CRM_Contribute_Form_Contribution_Confirm::processContribution() (line 1255 of civicrm/CRM/Contribute/Form/Contribution/Confirm.php).

We've had to disable this extension from automated distribution in CiviCRM because it's causing fatal errors on 4.7.23+ installs. This is because it is overriding CRM/Core/Payment.php which is no longer allowed for extensions. Please update your extension so it does not override any core files and request a review so we can get it approved again.

Although I see EFT available as a payment option on public pages, I don't see it on the back end. is that by design, or could something in my install be causing that?

When processing a back-office trasaction, I get the following error:

Notice: Undefined property: CRM_Contribute_Form_Contribution::$_separateMembershipPayment in CRM_Contribute_Form_Contribution_Confirm::processContribution() (line 1258 of civicrm/CRM/Contribute/Form/Contribution/Confirm.php).

We've installed the extension on Civi 4.4.14.

• installed extension
• created payment processor
• assigned to contribution page
• flushed civi cache

It looks like it displays the exact same fields a a credit card processor.

Should be be seeing different fields like account name, routing number, account number, account type?

Is there a working example we could look at?

Thanks
Dave

I have updated to the latest version of Civi and this is now working for me again. The only problem is it is only working when I am logged in as Admin. If I log out of Admin then I only get the option of the credit card (my default Payment Processor) and I do not have the option of using electronic check. Do you know if this is a permissions thing and if so what permissions might be causing this to not work?

Enabling the exsting in 4.5 results in the following API Error:

API error: Could not delete payment processor type

More information

There is a Payment Processor associated with selected Payment Processor type, hence it can not be deleted.

Seems like the 4.5 api error issue may be resolved now in 1.1.1 ?? I installed succesfully in 4.5.2.

However, when I attempted to use Submit Credit Card contribution, I get a spurious error:
"You will need to configure the live settings for your Payment Processor before you can submit credit card transactions." Even though I have both test and live settings filled in, and a front-end contribution page which I configured to include eCheck works properly. (Maybe this is a known bug / missing feature ??).

I went ahead and enabled the extension for automatic distribution in any case. Let me know if that's not appropriate at this point.

The payment_instrument_id on recurring transactions is being set to 1 (Credit Cards). It ought to be set to 5 (EFT).

Thanks!

We are trying to get this extension working (CiviCRM 4.7.23, Drupal 7), but when we enable it our contribution pages fail to load and we get the following error related to setBackOffice(). It does not matter what payment processor we have setup, it fails even with DummyTest. If I disable the extension the error goes away.

Call to undefined method CRM_Core_Payment_AuthorizeNet::setBackOffice() - /sites/all/modules/civicrm/CRM/Core/Payment/ProcessorForm.php:70 #13 /sites/all/modules/civicrm/CRM/Core/Form.php:829 - CRM_Core_Payment_ProcessorForm::preProcess(CRM_Contribute_Form_Contribution_Main) #12 /sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Main.php:66 - CRM_Core_Form->preProcessPaymentOptions() #11 /sites/all/modules/civicrm/CRM/Core/Form.php:543 - CRM_Contribute_Form_Contribution_Main->preProcess() #10 /sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php:92 - CRM_Core_Form->buildForm() #9 /sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php:203 - CRM_Core_QuickForm_Action_Display->perform(CRM_Contribute_Form_Contribution_Main, 'display') #8 /sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php:103 - HTML_QuickForm_Controller->handle(CRM_Contribute_Form_Contribution_Main, 'display') #7 /sites/all/modules/civicrm/CRM/Core/Controller.php:351 - HTML_QuickForm_Page->handle('display') #6 /sites/all/modules/civicrm/CRM/Core/Invoke.php:310 - CRM_Core_Controller->run(Array[3], NULL) #5 /sites/all/modules/civicrm/CRM/Core/Invoke.php:84 - CRM_Core_Invoke::runItem(Array[15]) #4 /sites/all/modules/civicrm/CRM/Core/Invoke.php:52 - CRM_Core_Invoke::_invoke(Array[3]) #3 /sites/all/modules/civicrm/drupal/civicrm.module:448 - CRM_Core_Invoke::invoke(Array[3]) #2 /includes/menu.inc:527 - civicrm_invoke('contribute', 'transact') #1 /index.php:21 - menu_execute_active_handler()

Since the user is able to modify the id's of the Payment Instruments:
http://example.com/civicrm/admin/options/payment_instrument?group=payment_instrument&reset=1

The value should not be hard-coded. Instead the admin should be able to modify the value that is used for the Payment Processor.