Add card on file outside of the checkout process

Still a drupal beginner but I am pretty sure I configured everything correctly, so let me know if this is some type of configuration issue.

The patch works great in Sandbox Accounts and Live Test Mode; however, when I switch everything over to a live account, I keep getting an Authorize.net API error #E00027. I checked into it and it seems the preauthorization requires zip code and billing address. The Authorize.net test mode seems to ignore those values since its not actively checking into the card. I looked through the XML output and the patch and I am pretty sure its not passing the zip code or address values from the customer billing profile. It could referencing the CIM billing address using another function, but I am not sure. If anyone could clarify if it is referencing the billing address from the CIM or some other method, that would be much appreciated.

I am going to try and muddle my way through this and see if I can get it working in live mode. Will post any results and any advice would be great.

Still a drupal beginner but I am pretty sure I configured everything correctly, so let me know if this is some type of configuration issue.

The patch works great in Sandbox Accounts and Live Test Mode; however, when I switch everything over to a live account, I keep getting an Authorize.net API error #E00027. I checked into it and it seems the preauthorization requires zip code and billing address. The Authorize.net test mode seems to ignore those values since its not actively checking into the card. I looked through the XML output and the patch and I am pretty sure its not passing the zip code or address values from the customer billing profile. It could referencing the CIM billing address using another function, but I am not sure. If anyone could clarify if it is referencing the billing address from the CIM or some other method, that would be much appreciated.

I am going to try and muddle my way through this and see if I can get it working in live mode. Will post any results and any advice would be great.

Still a drupal beginner but I am pretty sure I configured everything correctly, so let me know if this is some type of configuration issue.

The patch works great in Sandbox Accounts and Live Test Mode; however, when I switch everything over to a live account, I keep getting an Authorize.net API error #E00027. I checked into it and it seems the preauthorization requires zip code and billing address. The Authorize.net test mode seems to ignore those values since its not actively checking into the card. I looked through the XML output and the patch and I am pretty sure its not passing the zip code or address values from the customer billing profile. It could referencing the CIM billing address using another function, but I am not sure. If anyone could clarify if it is referencing the billing address from the CIM or some other method, that would be much appreciated.

I am going to try and muddle my way through this and see if I can get it working in live mode. Will post any results and any advice would be great.

Still a drupal beginner but I am pretty sure I configured everything correctly, so let me know if this is some type of configuration issue.

The patch works great in Sandbox Accounts and Live Test Mode; however, when I switch everything over to a live account, I keep getting an Authorize.net API error #E00027. I checked into it and it seems the preauthorization requires zip code and billing address. The Authorize.net test mode seems to ignore those values since its not actively checking into the card. I looked through the XML output and the patch and I am pretty sure its not passing the zip code or address values from the customer billing profile. It could referencing the CIM billing address using another function, but I am not sure. If anyone could clarify if it is referencing the billing address from the CIM or some other method, that would be much appreciated.

I am going to try and muddle my way through this and see if I can get it working in live mode. Will post any results and any advice would be great.

Still a drupal beginner but I am pretty sure I configured everything correctly, so let me know if this is some type of configuration issue.

The patch works great in Sandbox Accounts and Live Test Mode; however, when I switch everything over to a live account, I keep getting an Authorize.net API error #E00027. I checked into it and it seems the preauthorization requires zip code and billing address. The Authorize.net test mode seems to ignore those values since its not actively checking into the card. I looked through the XML output and the patch and I am pretty sure its not passing the zip code or address values from the customer billing profile. It could referencing the CIM billing address using another function, but I am not sure. If anyone could clarify if it is referencing the billing address from the CIM or some other method, that would be much appreciated.

I am going to try and muddle my way through this and see if I can get it working in live mode. Will post any results and any advice would be great.

I had to add this patch to enable this functionality. Otherwise it is basically impossible to get cards from users unless they are making a purchase on the spot, which isn't always the case.

I think if you need to pass more data through to CIM charging function, there is a hook_alter that can be used, 'commerce_authnet_cim_request'.

To add to this, you need to change the following as well in commerce_authnet_cim_cardonfile_create. Comment out the lines that load the current user, and set the $account as the UID assigned in the card data. Otherwise, it is impossible to enter cards as an administrator on other peoples accounts for them, winding up in assigning all cards to the current user no matter what account they are editing.

// should we get the uid elsewhere?
  //global $user;
  //$account = user_load($user->uid);
  $account = user_load($card_data->uid);

Also within that same function, references to $user should be $account.

Can anyone clarify what the combination of modules and patches are that are need to implement a card on file outside the checkout process? I'm running Card On File 7.x-2.0-beta2 and Commerce Authorize.net 7.x-1.1+5-dev. Should this patch do the trick? So far in testing I get the same issue as soberg with Authorize.net API error #E00027.

I've inherited a site with this module and various patches applied to it, including the one for this issue. I've encountered authnet error codes 27 and 3 sending the createCustomerProfileRequest. Try removing the line:

<?php 
$header[] = 'Content-length: ' . strlen($api_request_element->asXML());
?>

It's line #1589 for me, but I'm pretty sure my line numbers are way out of sync because of all the patching.

Actually, in my version, I had added the billTo address based on a user field. It is not yet fully resolved on my end, but I know removing that line in #10 did allow some requests to go through.

I have also found that authorize.net will return different errors if the XML elements are out of order. I managed to resolve this on our site by adding in billTo address (from user field) and also altering the XML element in a different module as follows:

<?php

function MODULENAME_commerce_authnet_cim_request_alter($api_request_element)
{
  # Re-order elements so billTo element is before payment element
  if (!is_null($api_request_element->profile->paymentProfiles->payment)) {
    $payment = $api_request_element->profile->paymentProfiles->payment;
    $payment_copy = new SimpleXMLElement($payment->asXML());
    unset($payment->{0});
    $api_request_element->profile->paymentProfiles->addChild('payment');
    append_simplexml(
      $api_request_element->profile->paymentProfiles->payment,
      $payment_copy
    );
  }
}

# copy simple xml elements and include children.
# http://pt.php.net/manual/en/ref.simplexml.php#91561
function append_simplexml(&$simplexml_to, &$simplexml_from)
{
  foreach ($simplexml_from->children() as $simplexml_child)
  {
    $simplexml_temp = $simplexml_to->addChild($simplexml_child->getName(), (string) $simplexml_child);
    foreach ($simplexml_child->attributes() as $attr_key => $attr_value)
      {
      $simplexml_temp->addAttribute($attr_key, $attr_value);
      }
    append_simplexml($simplexml_temp, $simplexml_child);
  }
}
?>

We need to re-roll this so that it doesn't include the patch from #2045269: Default card on file

Updated patch attached

Turns out that some Authroize.net accounts require a billing address with the card on file. I revised the patch to create a commerce_customer_profile and add the address form to the card on file create form. The profile that is created is saved to the card on file's commerce_cardonfile_profile field.

Note, this patch updates commerce_authnet_cim_billto_array() so that we can build the billing array without an order object.

Applied this patch and started testing. When I went to add a card I got an error:

Notice: Undefined index: organisation_name in commerce_authnet_cim_billto_array() (line 1090 of /home/ccmapp/public_html/sites/all/modules/commerce_authnet/commerce_authnet.module).

I'm not capturing a business or organization name in the form so I'm not sure how to address this.

I applied cleanly and it worked exactly as advertised, however...

• Notice: Undefined index: organisation_name in commerce_authnet_cim_billto_array() (line 1119 of /var/www/commerce_deploy/sites/all/modules/commerce_authnet/commerce_authnet.module). Backtrace:
• Notice: Undefined variable: remote_id in commerce_authnet_cim_cardonfile_create() (line 815 of /var/www/commerce_deploy/sites/all/modules/commerce_authnet/commerce_authnet.module). Backtrace:
• Notice: Undefined variable: cardholder in commerce_authnet_cim_cardonfile_create() (line 843 of /var/www/commerce_deploy/sites/all/modules/commerce_authnet/commerce_authnet.module). Backtrace:
• Notice: Undefined variable: cim_customer_profile_id in commerce_authnet_cim_cardonfile_create() (line 864 of /var/www/commerce_deploy/sites/all/modules/commerce_authnet/commerce_authnet.module). Backtrace:

commerce_authnet_cim_cardonfile_create() probably just needs some checks.

Here is a re-rolled patch to provide fixes.

Actually just RTBCing. Props to Andy, was able to add a card from user page and update the expiration date.

After investigating #2041809: Handling of duplicate customer payment profiles I realized that this does not account for duplicate profiles and throws an error. Working on updated patch.

Here is updated patch which handles duplicate CIM profiles when manually added.

I stubbed out a helper function commerce_authnet_cim_get_customer_profile_request() which request's the returned Customer profile (because the duplicate request doesn't return the duplicate payment profile!) This retrieves the profile and queries the entered card number against the returned payment profiles.

Reference to duplicate code not returning payment profile ID, why I went this route: https://community.developer.authorize.net/t5/Integration-and-Testing/Get...

I'm voting that this ticket blocks: #2041809: Handling of duplicate customer payment profiles with this stubbed out helper, as that requires the same kind of check to get a proper payment profile ID.

The duplicate is based on Customer Profile. The above patch covers if there is an existing profile and matching payment profile, but not if there is a customer profile and no payment profile.

Attaching a quick diff of what I did to check "if there are payment profiles. use existing, else create new". Needs a cleanup and some function name changes.

I'm unable to get the patch in #21 to work. Going to user/1/cards/add gives me a redirect loop, and there's no where else to add cards

@WillsCreative, try clearing your menu cache - that should resolve the redirect issue.

I have attached an updated patch & interdiff that attempts to handle the creation of payment profiles when a customer profile exists but no payment profiles exist (e.g. when customer deletes their last card on file, leaving no payment profiles left, and then attempts to add a replacement one).

Marking needs review as stewart.adam was so kind to reroll my hot mess.

I've applied the last patch against the latest dev (7.x-1.1+13-dev) and it appears to be working.

Thanks!

Testing patch and it is in fact working! However, I added a card on file, deleted it, then re-added it with same data and got the following messages on save. Going into super QA mode to try and break this as much as possible to hash out loose bugs.

• Notice: Trying to get property of non-object in commerce_authnet_cim_get_customer_profile_request() (line 1391 of /var/www/mojocart/sites/all/modules/commerce_authnet/commerce_authnet.module).
• Notice: Trying to get property of non-object in commerce_authnet_cim_get_customer_profile_request() (line 1391 of /var/www/mojocart/sites/all/modules/commerce_authnet/commerce_authnet.module).

Again, thanks to stewart.adam for sorting out my mess and coming up with patch in #25!

Here is an updated patch. Nothing introduced in #25, just a messed up implementation of the getCustomerProfileRequest endpoint in #21.

After investigating, stewart.adam in #25 wrapped up missing functionality and some dumb thoughts on my end. This patches removes clunk I added and keeps his work in tact to do what the original goal was.

Note: commit credit needs to go to stewart.adam for sure.

Thanks again for your work on this.

It was quite helpful in the work I did on Bank on File.

Issue on D.O.: #2556193: Overhaul to finish Bank on File integration

Patch updated to address some code styling / documentation issues. We needed more explicit documentation around the new parameter to commerce_authnet_cim_billto_array().

The only thing I'm unsure about is the current patch adds an unused function, commerce_authnet_cim_get_customer_profile_request(). I imagine this was supposed to have been used in commerce_authnet_cim_cardonfile_create() where we check for an E00039 error code. If not, do we really need to add this function?

Confirmed w/ mglaman, it looks like the function just bled into this patch from #2041809: Handling of duplicate customer payment profiles. Tested as working with my own developer test account. Committing!