Authorize.net missing second street address line

It sounds like your client is using the Authorize.net as her main dashboard for processing order. In general, I would discourage that because 1) Authorize.net will never have *all* the information associated with the order, it will only get a short summary (see below), 2) Orders entered through the admin interface and paid by check or PO or some other means will not show up in Authorize.net, and 3) Authorize.net can't track order status, as payment received is only one step in the workflow, and in particular Authorize.net has no notion of an order being *partially* paid for or not yet shipped, etc.

* (from above) For example Authorize.net only accepts/stores a short (255 character) text summary of the order, which Ubercart uses to send a comma-separated list of "qty x product name". That is NOT sufficient information to fulfill the order, as it does not contain attribute information and is likely to be truncated if there are more than a few different products in the order.

So while yes, we can and should concatenate address line 2 with address line 1, I don't think that's the fundamental error here, and your client will continue to have problems if she insists on managing orders solely through the Authorize.net interface.

ubercart-authorizenet-second-address-line.patch queued for re-testing.

It would be nice to get a review from someone who uses authorize.net ...

Can someone with an Authorize.net account please test this?

Looking for a review still. I don't want to commit a change like this which may disrupt someone's payment acceptance until at least one authorize.net user says it works and doesn't cause a problem. If this feature is of interest to you, please try it out and post your experience here.

Is this an issue for 3.3?

@DanZ: Yes, it is still an issue.

I personally prefer to deal with *all* issues in the current version of Ubercart first, but I didn't move this one to 7.x-3.x because it already has a supposedly good patch for 6.x-2.x attached. Given the level of interest shown by the community, requiring a new 7.x-3.x patch would be the equivalent of killing this feature entirely.

Patch applies to 7.x-3.x with minor fuzz anyway. I cleaned up the coding style a bit as well. I don't really see what harm this patch would do, although it would be nice to get a positive test result from someone who actually uses Authorize.Net.

We'll be implementing a site with Authorize.net in the next couple weeks (we hope). I'll give it a shot.

Tested #10 with a few transactions on the Authorize.net sandbox. Works great.

Committed to both branches.