Add support for eCheck.Net

Ahh, good point. I'd totally forgot about eCheck.Net, but yes, it makes perfect sense to add support for that as a module to this project.

It can be a part of this project, as it's the same service, but it would most likely be a separate module within this project. I'd have to revisit my past work to see how similar the API requests and stuff are... might mean we need to split up the code of the base Authorize.Net module.

I'm interested in this as well. For UC, I separated your eCheck.net module into a specific payment method and created my own Authorize.net gateway (based on http://drupal.org/project/uc_authnet). This allowed me to use the same gateway code for most of the transaction process - only adding/removing fields passed to the gateway based on the payment method. I could then reuse the echeck method for other gateways (like ACH).

Would you be open to adding a comerce_payment.echeck.inc payment method to Commerce? This could provide the base forms, potential validation, etc, and allow gateway modules to add the necessary Commerce panes for each method but maintain 1 'transaction process' function.

Or, maybe a better question, is that even a good route? If not - can you clarify?

Here's my eCheck payment method - it's based entirely on the core credit card method and requires that the individual payment gateway implements it.

SO - I currently have an altered commerce_authnet module that includes "authnet_aim" and "authnet_echeck" with a couple of switches based on the transaction.

One question/issue would be how to address using the same gateway with different methods without having multiple configuration forms in Commerce/Rules.

It would be great if there is any feedback.

Oooh, thanks for posting the code. As to your particular question, I just don't think it'll be possible right now. We have some thinking to do with respect to payment method configuration for 2.x that this can play into.

@avr,
I just downloaded your echeck module code. Where do I place it and how do I enable it?

@rhodet

http://drupal.org/node/70151

EDIT:

Let me add that this isn't a full-fledged, finished and tested module, so your mileage may vary.

@avr

I don't see any changes to my site with your module enabled. I'm guessing it's not quite there? I'm happy to help test, but I'd need some more info about intended usage/configuration.

@rhodet, @rhodet...

This module doesn't actually do anything for Commerce other than provide the fields/validation to collect bank checking/savings account information.

A payment gateway (like an altered commerce_authnet mentioned above) would need to define a echeck_web payment type and implement commerce_payment_echeck_form to present the fields to the user during checkout. Then (in the payment gateway module) process those fields by sending them to the payment processor.

@avr

I'm starting to work on this - any chance you could share your commerce_authnet changes somewhere?

For my use case, I'm fine repeating myself a bit and setting up a separate payment gateway for eCheck - not everyone will be presented with the option to use eCheck anyway.

@glennpratt

Unfortunately, the project that I was working on switched to a different payment processor - and moved away from Commerce. I've tried to dig up my code but can't track it down.

Would have loved to help!

Here's a totally untested patch just to show the direction I'm headed. Probably need to propose the eCheck form in an upstream issue or rename it.

OK, this one is actually tested with the test gateway.

Moved the default echeck form to a Commerce issue #1661548: Add ACH / Echeck default form., so now this patch depends on that patch!

http://drupal.org/node/1661548#comment-6166286

glennpratt -- Thanks for all of your work on this! I'm looking forward to seeing your patches committed.

@glennpratt,
You edited the commerce_authnet.module file to create this patch. You should create a new module in a subfolder of commerce_authnet. There should be little to no changes to any of the existing commerce_authnet code. Your patch at that point would contain the information to create the new folder(s) and files when applied. If you look at the current patch you've submitted, it deletes all of the code from the authnet module and replaces it with yours. Yikes! :D

@glennpratt,

After digging in deeper, I see what you did by splitting out the two modules into submodules. Sorry for jumping the gun on the review. However, I cannot get the patch to apply to the current 7.x.1.x. Can you update your patch so that it can be applied and I'll give it a review?

Sorry, I built this against the version we were using before I realized it was horribly old. I'll try to update soon.

Just marking this postponed to make it clear it won't be a part of the initial full release of this module. Would love to get a clean patch to make it a reality, whether that's Glenn or someone else with time. : )

Attached patch is an update to #15 applied to the latest HEAD from git with the following additional changes:

• Fixed some minor spacing issues.
• Fixed a fatal caused by trying to load an include from the wrong module.

Setting back to needs review with the understanding that this will not make it into 1.x.

Also of note, eCheck.Net supports CIM as well, but commerce_cardonfile (as the name implies) only supports credit cards.

Last patch does not apply properly, rolled a new one.

Not quite sure what happened to the last one, but this one should be right. This one also includes a type fix and rolls in the patch from #1 on #1810088: Typo in card declined message as the two can not be applied together.

Had a typo in the last patch.

+  $payment_methods['authnet_eheck'] = array(

Moved commerce_authnet_avs_response() back to commerce_authnet.module so that it can be used by commerce_cardonfile callbacks.

.

Tried to get echeck working with patches (25 & 26) above. Both patches failed for Kickstart version, Dev 7.x.1.x-dev version and current version with the following errors:

COMMAND RUN >>> patch -p1 < patch.file

PATCHING ERRORS PRODUCED:

patching file commerce_authnet.module
Hunk #1 succeeded at 161 (offset 1 line).
Hunk #2 FAILED at 192.
Hunk #3 FAILED at 394.
Hunk #4 FAILED at 729.
Hunk #5 FAILED at 1395.
4 out of 5 hunks FAILED -- saving rejects to file commerce_authnet.module.rej
patching file includes/commerce_authnet_payment.cc.inc
patching file includes/commerce_authnet_payment.echeck.inc

HTML/PHP LOGS ERROR:

Cannot redeclare commerce_authnet_aim_settings_form() (previously declared in /var/www/html/PLT-DRUP-KICKST.2.11/profiles/commerce_kickstart/modules/contrib/commerce_authnet/commerce_authnet.module:199) in /var/www/html/PLT-DRUP-KICKST.2.11/profiles/commerce_kickstart/modules/contrib/commerce_authnet/includes/commerce_authnet_payment.cc.inc on line 88, referer: http://www.practicalleasedtime.com/admin/commerce/config/payment-methods...

Any suggestions? Also are there plans on making these patches a part of the commerce_authnet module versions in the near future?

Anyone Help?

Here is an updated patch for 7.x-1.1.

Here is an updated patch for 7.x-1.x.

Edit: This is an incorrect update to the patch, it can be ignored.

Here is an updated patch for 7.x-1.x.

Sorry about that, the previous patch does not include the new files. Fixed on this one.

Adding some things that was missing. I've tested eCheck transactions with this patch and works fine!

Last patch is not working. I apply it, and the previous patch to 7.x-1.x. When I do so, there are no settings for me to enter my api/tran key under payment method rules: Enable payment method: Authorize.Net AIM - Credit Card.

I revert to before patch, the settings are there for me to enter api/tran key. I am using an authorize.net sandbox to test with. After the patch, I have no form to enter credit card info, and transaction does not show up in my list at authorize.net.

Suggestions?

I'm testing the last patch on a brand new environment and I'm perfectly able to enter API credentials for both payment modes (CC and eCheck).

I don't know, maybe clearing caches might solve the problem.

I have clear caches, and I even did drush dre reinstall of commerce_authnet after applying patch, twice. Both times I lost the settings in the actions of the Authorize.Net AIM - Credit Card, as soon as patch is applied. This is on a commerce kickstart distribution.

I've been using #31 on a live site for awhile now. One thing that I've been running up against consistently is the 22 character limit on nameOnAccount imposed by eCheck.net when used with CIM. While this doesn't affect normal transactions, it causes the creation of billing profiles to fail.

I've had the same experience as cfgregory. When I apply either of the patches the fields for adding authorize.net credentials disappear. I've tried this on my current site as well as a fresh commerce kickstart install.

The only problem I had was with an error Call to undefined function commerce_payment_echeck_form(). I traced it down to the prerequisite patch mentioned in #15: http://drupal.org/node/1661548#comment-6166286

If that patch is run inside the commerce_authnet module, it creates an include file located at:

modules/payment/includes/commerce_payment.echeck.inc

This patch here in #36 has an include on line 73 for the new file like so:

module_load_include('inc', 'commerce_payment', 'includes/commerce_payment.echeck');

But if you install the referenced patch from #15 inside the authnet_commerce module like I did, you will need to change line 73 to this:

module_load_include('inc', 'commerce_authnet', 'modules/payment/includes/commerce_payment.echeck');

This might only be specific to me, as to how I installed the referenced patch...

My apologies, as I just realized I made this patch against the 7.x-1.3 version of the module as opposed to the dev.

Nonetheless, if you'd rather not patch commerce_payment in order to use one of the above patches, this one puts everything in the commerce_authnet module.

This is functioning for my case, but has not been fully tested yet. Please let me know if you find any issues.

Cheers.

The patch above has some issues. Better yet, I've a stand alone module that accomplishes this now:

https://www.drupal.org/sandbox/actorrunning/2716153

@actorRunning is your module still running well with current the commerce_authnet module?

Is anyone else using this?