I'm running into a problem with how information is passed to authorize.net. Currently the attributes do not get passed, but this can be a headache for the bookkeepers because they rely on emails generated by Authorize.net. In my case I am doing tuition payments that require a name (text attribute) to apply the payment to. Since only the SKU and quantity are passed per product the bookkeepers cannot know who to apply the payment to.
Proposal
Allow attributes to be passed along with the product information during an authorize.net transaction. This will allow the person who is reconciling authorize.net transactions to easily know the extra attribute information without having to receive another email or logging into the store.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | uc_authorizenet.qb_line_items.6.x-2.4.patch | 5.12 KB | ezra |
| #7 | PATCH_INFO.txt | 768 bytes | ezra |
| #6 | uc_anet_qb.patch | 4.8 KB | eileenmcnaughton |
Comments
Comment #1
rszrama commentedI believe there's a length limitation on the order description field through which this data is being passed that might get in the way. Can you research that and make a proposal based on that information? Are we passing in SKUs? If not, perhaps it would be wiser to do that than to do every attribute.
Comment #2
ajeancharles commentedCreate an invoice number (x_invoice_num) that you associate with buyer's order, send it along with transaction. Authorize.net will send it back with transaction record
Comment #3
willvincent commentedIt already creates an invoice number set to the same value as the order number in ubercart.
Comment #4
jdwfly commentedI barely looked into this because we got our bookkeepers to rely on the emails from ubercart instead. It's kind of a pain and probably not worth it from what I remember. There were several length restrictions, etc.
Comment #5
tr commentedIf someone wants to do the research and make a proposal as suggested in #1, please feel free to reopen this issue.
Comment #6
eileenmcnaughton commentedHi,
I'm a bit unclear on whether issues go on the ubercart site or on the drupal site.
I did log a patch on ubercart site for this and have attached it here
http://www.ubercart.org/project_issue/authorizenet_should_pass_informati...
I think I've commented what I've done quite heavily in the patch because I wasn't sure if other's would agree but basically I stole a function from another payment processor I wrote that :
1) url_encodes the value
2) checks if it has cut off half way through a urlencoded character
3) truncates back a bit if so
description field needs to be no more than 31 characters
Note that this is primarily so that quickbooks iif imports from authorize.net hold extra information about line items and tax/ shipping
Comment #7
ezra commentedThanks Eileen, that patch came in handy for me. It looks like it does the job well and is well written. I've modified it slightly to work with the current release of Ubercart. I'm not certain that this will work on everyone's site -- I'm not so crazy about the 'magic numbers' included on array references. That said, it worked well in our case and can be used as a basis for anyone else who need to apply Eileen's patch to the current uc_authorizenet release.
The patch should be applied to the uc_authorizenet.module file.
Comment #8
longwaveComment #9
tr commentedUsual disclaimer - testbot is probably going to fail because it's not working right yet. If so, it's not the patch's fault.
I like the idea. I have faced similar issues with other payment gateways I've written, which leads me to ask if this logic should be put into a function in the uc_payment module so it could be used by any gateway? I don't see the need to replicate this sort of code in every gateway. uc_paypal, for instance, has a function called _uc_paypal_product_details() which has a similar purpose.
Comment #11
tr commentedNew features should go into 7.x-3.x first.
Comment #12
Anonymous (not verified) commentedThanks for this patch you guys! Trying it out on one of our sites.
ps. I ran it through Drupal's "Dreditor" greasemonkey script and it looks like there are only a few small things, besides it being a D6 patch, that would prevent it from being accepted to the main branch. Most of it is excess spacing at the end of lines, a tab(?) on one end of line, and the comments are often longer than 80 characters per line. As per a note above, the diff could be produced with git and then it would pass the tests after fixing the spacing and line length issues. Though, for it to be really accepted it would have to be for D7 and backported. :,(
Anyway, that said, fingers crossed that it covers our use case... thanks.
Comment #13
DanZ commentedClosing #1894010: Itemize products, tax, and shipping in Authorize.net transactions as a duplicate. Read it for some more details.
See http://developer.authorize.net/guides/AIM/wwhelp/wwhimpl/js/html/wwhelp.... for documentation of the API.
The patch here need more work. It does not use the x_tax and x_freight items for tax and shipping, and it has a "donation" line item, which is puzzling.
Comment #14
longwaveThe "donation" line item is actually commented out, but seems to be an attempt to support http://drupal.org/project/uc_add_donation
Comment #15
DanZ commentedAh, that explains it.
This also doesn't report SKUs, but gives a truncated description, instead. It should use SKUs in the short description because Quickbooks uses SKUs.
Comment #16
tr commented