Support for Card on File create callback (and review of update callback)

Hi Rick
I can confirm that this is possible with the cardonfile_create callback to create a new card for a user and get the token from Hosted PCI. I ended up forking the HPCI module to add this but I can work on getting a patch posted here next week when I get back in the office. For my application, we decided not to initiate a purchase of $0 to validate the new card, we just save the token we get back.
The primary function of Commerce on our site is to sell monthly recurring subscriptions and process the renewals, so being able to create a new card without making a purchase is pretty much a requirement.
Apologies for the delayed response - I've been out on vacation.

I got a patch created today with the changes for new card creation. This also includes some updates to allow users to update the billing address of an existing card. I have not tested this at all yet, but I plan to get to that tomorrow.

Here's an updated patch after some testing I did this morning. I built up a small sandbox with Commerce, Commerce Recurring, Commerce Cardonfile, and Commerce HPCI. I configured HPCI to connect to my Auth.net test gateway. I was able to add a card and set it as a default, and that card was used when a Recurring order was triggered by Cron.

What's not working:
A customer profile is now associated with each cardonfile. This is created either by copying the profile from the order being checked out if a new card is created that way, or via the fields in the create card page if the user is just adding a card (i.e. not performing any operation on an order). The address can be changed using the cardonfile update form.

Obviously once an order has been completed we don't want to change the customer profile associated with it, but customers will need to updated the address associated with their card any time they move, etc. That updated address must be used when Commerce Recurring creates an order via cron, because the address is usually required for AVS verification.

It appears that with this patch, the old address is still being used when Commerce Recurring creates an order (it just copies the address from the previous order). This is working correctly in my forked version of HPCI, so I probably missed something.

Will spend more time debugging tomorrow, but I think this is ready for you to test Rick.

Found what was causing the issue in my previous comment. This new patch fixes the issue where new recurring orders were using the billing profile from the original recurring order. They now use the billing profile from the card instead so the most current address information is used to process.

Back to the change in #11:

I'm not sure how that works..

The HPCI Card Update callback calls the commerce_cardonfile_card_form() function:

function commerce_hosted_pci_cardonfile_update_form($form, &$form_state, $op, $card_data) {
  $form_state['op'] = $op;
  
  //Get the card form & make sure the 'credit_card' fieldset is shown first
  $form = commerce_cardonfile_card_form($form, $form_state, $op, $card_data);
  $form['credit_card']['#weight'] = -10;
  $form['submit']['#weight'] = 20;

  ...
}

Meanwhile, in the commerce_cardonfile_card_form() function, the card data is saved to $form_state['card'], not $form_state['card_data']:

function commerce_cardonfile_card_form($form, &$form_state, $op, $card) {
  // Load the credit card helper functions from the Payment module.
  module_load_include('inc', 'commerce_payment', 'includes/commerce_payment.credit_card');

  // Pass along information to the validate and submit handlers.
  $form_state['card'] = $card;
  $form_state['op'] = $op;
  ...
}

I hooked up the debugger and found that in the commerce_hosted_pci_cardonfile_update_form() function, $form_state['card'] is set, but $form_state['card_data'] isn't.

However I'm also not sure how both of you guys could get this to work using $form_state['card_data'], so something doesn't make sense here...

Well I found what might be our problem - check out commit f3774f5 for the Card on File module:
http://cgit.drupalcode.org/commerce_cardonfile/commit/?id=f3774f5c249f1e...

Looks like between beta 2 and beta 3 they changed a lot of the variable names from 'card_data' to 'card'. The line in question above changed from
$form_state['card_data'] = $card
to
$form_state['card'] = $card

Can you guys confirm which version of Card on File you used to test this patch? I'm on beta5.

Moving back to Needs review until we confirm whether or not something needs to change.

Bump

@rickmanelius @arknoll - Can you confirm the version of Card on File you used for your testing?

Interesting. It seems to me that the card data should be showing up as $form_state['card'], rather than $form_state['card_data'] if you're using beta 4 based on that commit above.

I'll take a look again when I get back to the office on Monday.

I applied the patch in #11 and it does not work for me. Just to confirm, I'm using Card on File beta 4. After applying the patch in #11 and trying to edit an existing card, I get the following warnings & exception:

• Notice: Undefined index: card_data in commerce_hosted_pci_cardonfile_update_form_submit() (line 1107 of /Users/jmeier/Sites/drupal7/sites/all/modules/commerce_hosted_pci/commerce_hosted_pci.module).
• Notice: Trying to get property of non-object in commerce_hosted_pci_cardonfile_update_form_submit() (line 1109 of /Users/jmeier/Sites/drupal7/sites/all/modules/commerce_hosted_pci/commerce_hosted_pci.module).
• Warning: Creating default object from empty value in commerce_hosted_pci_cardonfile_update_form_submit() (line 1111 of /Users/jmeier/Sites/drupal7/sites/all/modules/commerce_hosted_pci/commerce_hosted_pci.module).
• PDOException: SQLSTATE[HY000]: General error: 1364 Field 'payment_method' doesn't have a default value: INSERT INTO {commerce_cardonfile} (card_name, card_exp_month, card_exp_year) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => Jeremy Meier [:db_insert_placeholder_1] => 7 [:db_insert_placeholder_2] => 2017 ) in drupal_write_record() (line 7207 of /Users/jmeier/Sites/drupal7/includes/common.inc).

Debugging, I found that when the commerce_hosted_pci_cardonfile_update_form_submit() function is called, $form_state['card_data'] is not set, while $form_state['card'] is. So after line 1107, the value of $card_data is NULL. So the warnings & exception above make sense. The only data that exists for $card_data prior to saving on line 1118 is card_name, card_month, card_year, and the commerce_cardonfile_profile field.