Authorize.net ARB subscription created before card is validated

That doesn't sound like behavior Authorize.net should be allowing, no matter what's coming from the uc_recurring module. I suggest following up with Authorize on this issue.

Please test the patch in http://drupal.org/node/1458128

Hi,

I think this issue is different than the issue found in http://drupal.org/node/1458128.

This issue occurs during the initial checkout process. If a customer attempts to submit an order that is declined, the transaction is declined. However, this module has already created a recurring fee and posted to Authorize.net, which creates an ARB Subscription with credit card details that will be declined at renewal time.

I think the uc_recurring could avoid this by processing after checkout is complete.

The issue described in http://drupal.org/node/1458128 occurs after the initial checkout and subscription is created when the subscription renewal.

Hi,

For anyone testing this with their developer authorize.net account, use the following zip code, 46282, in the billing address along with the test card #4444333322221111, to simulate a declined transaction. You can use other zip codes and CVVs to simulate other decline codes, see attached.

Using this zip code, your initial checkout will fail. However, if you check your ARB Subscriptions in your developer authorize.net account (found at sandbox.authorize.net under Tools > Recurring Billing), you will find a new subscription has been created.

Thanks, Jason.

Just changing title.

It appears that the uc_cart_checkout_review_form_submit function invokes the hook_order function by iterating over the list of modules returned by module_list(). Because uc_recurring_product has the same weight as uc_credit, uc_recurring_product_order can be executed before uc_credit_order. This means that the subscription will be validated and created before the CC validation occurs. This is a non-issue if the CC information is all correct, but creates problems if the CC information is invalid.

In comment #1: #1394050-1: Authorize.net ARB subscription created before card is validated, ferdinand.bardamu suggests that this is a problem with how authorize.net functions. This is probably true, but their issue can be avoided by validating the CC first. Either way, the CC should be determined to be valid before any attempt to create subscription in my opinion.

If we adjust the module weight of uc_recurring_product from 0 to 1, then uc_recurring_product_order is guaranteed to be executed after uc_credit_order has completed the CC verification. This seems like the best solution to me and I have seen no issues in my own testing, but I am unsure of any other impact that adjusting the weight of the module will have outside of my own testing. I suspect that there will be no impact, but could use some community testing.

I'm attaching a patch that will add a new update function to uc_recurring_product.install. Apply the patch then run update.php to test.