Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Is there any plan to add support for eCheck.Net, either through this Authorize.Net module, or another?
Comments
Comment #1
rszrama CreditAttribution: rszrama commentedAhh, 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.
Comment #2
archimedes CreditAttribution: archimedes commentedWould eCheck.Net support be added within this Authorize.Net module, or as a separate module?
Comment #3
rszrama CreditAttribution: rszrama commentedIt 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.
Comment #4
avr CreditAttribution: avr commentedI'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?
Comment #5
avr CreditAttribution: avr commentedHere'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.
Comment #6
rszrama CreditAttribution: rszrama commentedOooh, 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.
Comment #7
rhodet CreditAttribution: rhodet commented@avr,
I just downloaded your echeck module code. Where do I place it and how do I enable it?
Comment #8
scottrouse CreditAttribution: scottrouse commented@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.
Comment #9
scottrouse CreditAttribution: scottrouse commented@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.
Comment #10
avr CreditAttribution: avr commented@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 implementcommerce_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.Comment #11
glennpratt CreditAttribution: glennpratt commented@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.
Comment #12
avr CreditAttribution: avr commented@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!
Comment #13
glennpratt CreditAttribution: glennpratt commentedHere'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.
Comment #14
glennpratt CreditAttribution: glennpratt commentedOK, this one is actually tested with the test gateway.
Comment #15
glennpratt CreditAttribution: glennpratt commentedMoved 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
Comment #16
rchuber CreditAttribution: rchuber commentedglennpratt -- Thanks for all of your work on this! I'm looking forward to seeing your patches committed.
Comment #17
andyg5000@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
Comment #18
andyg5000@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?
Comment #19
glennpratt CreditAttribution: glennpratt commentedSorry, I built this against the version we were using before I realized it was horribly old. I'll try to update soon.
Comment #20
rszrama CreditAttribution: rszrama commentedJust 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. : )
Comment #21
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedAttached patch is an update to #15 applied to the latest HEAD from git with the following additional changes:
Setting back to needs review with the understanding that this will not make it into 1.x.
Comment #22
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedAlso of note, eCheck.Net supports CIM as well, but commerce_cardonfile (as the name implies) only supports credit cards.
Comment #23
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedLast patch does not apply properly, rolled a new one.
Comment #24
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedNot 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.
Comment #25
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedHad a typo in the last patch.
Comment #26
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedMoved
commerce_authnet_avs_response()
back to commerce_authnet.module so that it can be used by commerce_cardonfile callbacks.Comment #27
pinkonomy CreditAttribution: pinkonomy commentedHi,
is this patch (e-check) for bank transfers?
Also is there available a recurrint options payment with this patch?
Also is this possible to show the e-check block in another(german) language?
thanks
Comment #28
archimedes CreditAttribution: archimedes commentedThis patch is for integration with Authorize.Net's eCheck.Net service, which are essentially bank transfers. However, they are through the eCheck.Net service (not just general bank transfers), which means you need an eCheck.Net account.
I don't think so, but I haven't yet tested the patch. The recurring options is integrated separately. Anyone have any feedback on if that type of thing would go in this issue, or if the work happening elsewhere (http://drupal.org/node/1418348) would also work with eCheck.Net?
I don't actually know, perhaps someone else could answer this...
Comment #29
lvto_2000 CreditAttribution: lvto_2000 commentedTried 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?
Comment #30
lvto_2000 CreditAttribution: lvto_2000 commentedAnyone Help?
Comment #31
bdlangton CreditAttribution: bdlangton commentedHere is an updated patch for 7.x-1.1.
Comment #32
bdlangton CreditAttribution: bdlangton commentedHere is an updated patch for 7.x-1.x.
Comment #33
bdlangton CreditAttribution: bdlangton commentedEdit: This is an incorrect update to the patch, it can be ignored.
Comment #34
bember CreditAttribution: bember commentedHere is an updated patch for 7.x-1.x.
Comment #35
bember CreditAttribution: bember commentedSorry about that, the previous patch does not include the new files. Fixed on this one.
Comment #36
bember CreditAttribution: bember commentedAdding some things that was missing. I've tested eCheck transactions with this patch and works fine!
Comment #37
cfgregory CreditAttribution: cfgregory as a volunteer commentedLast 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?
Comment #38
bember CreditAttribution: bember commentedI'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.
Comment #39
cfgregory CreditAttribution: cfgregory as a volunteer commentedI 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.
Comment #40
merauluka CreditAttribution: merauluka commentedI'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.
Comment #41
Menace Ren CreditAttribution: Menace Ren commentedI'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.
Comment #42
Rev314159 CreditAttribution: Rev314159 commentedThe 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-6166286If 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...
Comment #43
aaronglamb CreditAttribution: aaronglamb as a volunteer commentedMy 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.
Comment #44
aaronglamb CreditAttribution: aaronglamb as a volunteer commentedThe patch above has some issues. Better yet, I've a stand alone module that accomplishes this now:
https://www.drupal.org/sandbox/actorrunning/2716153
Comment #45
83steps CreditAttribution: 83steps commented@actorRunning is your module still running well with current the commerce_authnet module?
Is anyone else using this?