notices on review order page

I'm getting the following errors in my log report when trying to process a credit card:
Notice: Undefined offset: 3 in commerce_authnet_aim_submit_form_submit() (line 327 of ../sites/all/modules/commerce_authnet/commerce_authnet.module).
Notice: Undefined offset: 38 in commerce_authnet_aim_submit_form_submit() (line 327 of ../sites/all/modules/commerce_authnet/commerce_authnet.module).
Notice: Undefined offset: 5 in commerce_authnet_aim_submit_form_submit() (line 327 of ../sites/all/modules/commerce_authnet/commerce_authnet.module).
Notice: Undefined offset: 6 in commerce_authnet_aim_submit_form_submit() (line 327 of ../sites/all/modules/commerce_authnet/commerce_authnet.module).
Notice: Undefined offset: 11 in commerce_authnet_aim_submit_form_submit() (line 327 of ../sites/all/modules/commerce_authnet/commerce_authnet.module).

I tried using the patch you posted, but that did not work for me. It got rid of the credit card field and the log printed out the same types of errors. Tried this one too: http://drupal.org/node/1441364

Do you know why we're getting all these Notice:Undefined offset errors?

getting this too...first attempt at a DC site and stuck already! :(

Not sure if this could be related, but #1328762: Credit card rejected/declined, order goes through anyway #7 i also just posted...i create the order, check out, first order i didn't get this commerce_authnet_aim_submit_form_submit() error, but checkout complete page gave me a link to my new order but it's not there...watchdog shows a good reply from auth.net (in test mode) but no orders are shown in admin/commerce/orders. got emails from both the site and auth.net though!

did one more time, got the commerce_authnet_aim_submit_form_submit() mentioned in this OP, the credit card form wasn't rendered so i just hit "continue to next step", it processed the card and seemed to create another order, but again, nothing in my orders tab, nothing in the orders admin page, but emails and messages indicate a successful order!

Help us, rszrama-wan kenobi, you're our only hope ;) Maybe pcambra could too? Enjoying those commerce tuesday videos! :)

looks like this module makes several assumptions about using the organisation (optional) and name fields (either first_name and last_name separate or the single name_line) being used, but when you set up an addressfield as part of the billing profile fields, these can be unchecked. i tried to make some changes and managed to get around the errors but began getting something about 'a valid amount is required' so whatever I did didn't work. point is, the module should be able to be configured somewhere in the UI - I've got first and last as separate fields form the addressfield field for various reasons and don't need a company/organization field for this site - to grab those values (at least the names, which I'm sure are required on the authnet side) from other fields in the customer billing profile.

As long as I enable the organization field and one of the name fields within the customer billing profile's addressfield field, this doesn't come up at all and things go as expected...but since these fields are optional and can be unchecked, this should be corrected somehow...

similar issue over at commerce_cardonfile? posted #1571766: Notice: Undefined index: cim_cardonfile in commerce_authnet_aim_submit_form_submit().

The patch in #1 cannot be applied within the commerce_authnet module directory without editing. Here's an update that has inline checks to prevent undefined indexes on any billing address fields. Also, changing to task since the original issue in #1 is just throwing a PHP notice. Other problems mentioned above are unrelated to this issue and appear to have their own issue already.

Discussed this with Andy, and I can commit his patch as is, but honestly I don't know how you're ending up with an addressfield value that has missing indexes. Theoretically, any time an entity with an addressfield is loaded and the entity metadata wrapper is used to retrieve its value (as in this module), all the indexes should be initialized to their default values. I can do a quick bit of testing to try and generate a broken array, but really I'd love to hear from the reporters how you had configured your billing profiles / addressfields.

I understand Ryan's hesitation to simply commit #7 because there is probably something misconfigured. Additionally, the patch in #7 may actually make it harder to debug said misconfiguration because the errors would no longer be visible.

I guess it really boils down to what Scot mentions in #5. If the billing profile address field allows for fields to be optionally on or off, then #7 seems like it would be necessary to prevent missing indexes (unless I'm not fully understanding why they could never be missing as per Ryan's comment #8).

To move forward, either we need a specific configurations from vlkff or scotself... or we need to know if patch #7 removed the errors without introducing any major AVS problems from authorize.net.

Moving this to "needs more info" and will close it eventually if we can't determine how to reproduce the configuration that generated the notices.

if i come across this again, i'll be sure to report back, but i've moved back to UC for this project though...

Ok, and I'll look into the Address Field configuration affecting the available data in a customer profile. To be honest, I'd expect all schema columns to at least be present in the array, even if they aren't editable via the form. It sounds like a bug to me in that module that they aren't. But fwiw, you need to be sending the whole address to Authorize.Net anyways, so I'm not sure if we need to support just sending a name or not. : ?

I was able to replicate this Notice when moving the Payment pane from the Review page to the Checkout page without adding Organisation to the commerce_customer_address field.

Same results as bleedev (#13) here. Moving the Payment pane to Checkout causes the error to appear. Moving the Payment pane back to Review solves the issue.

Would love to be able to put the payment pane in Checkout without requiring a patch...

Hi there, any update on the issue? Seems like it affects single page checkouts.. Anyone else facing similar issues? I am planning to use this module for single page checkout.

Hello, I'm running version 7.x-1.1 with the setting "Test transactions in a live account" and the payment pane on the Review Order page. I am using dummy credit card numbers that are supposed to work for testing and receiving the same undefined offset errors. My billing and shipping addresses use the single line name field. I tried both sending the request without a company field in the address, and also with the field enabled and filled. The behavior was the same.

Thought I'd report back that this issue was fixed for me after I checked my settings for credit card processing at my processor's website. My processor uses an Authorize.net emulation, and I had not set this as an available processing method for my transactions. After I changed this setting on their website, all is well and cards are being processed as either Approved or Denied rather than throwing the error.

Same results as bleedev (#13) here. Moving the Payment pane to Checkout causes the error to appear. Moving the Payment pane back to Review solves the issue.

If this is the case then this issue won't be fixed. As soon as the payment form is submitted the transaction is processed, not after "review" is submitted (because Commerce would have to worry about stashing that information securely.) There's a node out there, somewhere specifying why Commerce did this.

Thank you for the patch rsmylski :)

@mglaman what is when you don't want that extra review page? I think this patch should be definitely committed.

@yannickoo - I totally misunderstood use case in my initial comment. We just implemented a single checkout page (no review pane, etc.) Error throws, patch fixes it up. +1 from me on this patch.

Out of curiosity, are you guys adding address data in later before this API request gets submitted to Authorize.Net? Isn't that required for AVS checks?

Ryan's right. After working with this, the reason it's undefined is because the order isn't saved so it doesn't have access to any addresses.