| Project: | Ubercart |
| Version: | 6.x-2.x-dev |
| Component: | Payment |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
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.
Comments
#1
I 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.
#2
Create 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
#3
It already creates an invoice number set to the same value as the order number in ubercart.
#4
I 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.
#5
If someone wants to do the research and make a proposal as suggested in #1, please feel free to reopen this issue.
#6
Hi,
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
#7
Thanks 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.
#8
#9
Usual 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.
#10
The last submitted patch, uc_authorizenet.qb_line_items.6.x-2.4.patch, failed testing.