Well after some investigation with Authorize.net, my understanding is they are able to process recurring payments without the need for CVV. Since it has been provided during the first transaction, the customer effectively becomes "validated" according to Authnet. As long as the transaction includes the same name, address, credit card number, etc., then Authorize.net will process the transaction.

Auth.Net will let you setup either recurring fees through their ARB system or reference transactions through their CIM system. I'm not sure what fees are associated with your account should you enable either one of these. The core Auth.Net module provides some integration for ARB through uc_recurring, but it's still a little rough around the edges. It's in development, mostly sponsored by Digital Dollhouse. I'm still working through some reporting issues, because Auth.Net doesn't have a really good mechanism for testing out ARB payment notifications.

So, Ryan, I've seen in a few places you've mentioned that Authorize.net ARB is a little rough and it would be great to understand in what ways. How does ARB talk back to the UC site? What is stored in the DB if ARB holds all of the subscription information? We're looking at using the CIM module, but ron_s pointed out that it's not working properly with UC 1.6. So the situation with subscriptions right now is a bit confusing! I'd actually like to start a Subscriptions focus group here on the UC site to collect all known info into a single location. Thoughts?

For anyone interested, you may want to check out the following thread that has had an on-going conversation of some of the pros/cons and strengths/weaknesses. I've dissected what I consider to be a lot of the key issues:

http://www.ubercart.org/forum/support/6791/expiring_roles_and_recurring_...

Regarding subscriptions, recurring fees, role expiration, CIM, etc. ... I have run ARB on a site and I can tell you while it may be a "little rough", it is 100x more effective than the current state of CIM. Nothing against CIM, I think it will be a solid approach in the long run, it's just not there today.

When running ARB, the database does store an encrypted version of the credit card number. It uses this when processing a new recurring transaction. When the transaction information is sent to Authnet, they identify a previous transaction that has the same credit card number, name, and address information, and if there is a match, the transaction is processed.

Hey Ron, just wanted to say I haven't forgot about the issues here... I've just been knee deep in a couple of client sites and preparations for Do It With Drupal. I did want to refine your comments here a small bit... Authorize.Net is the one storing the payment information in accordings w/ the PCI DSS. The Ubercart database does not store the CC number. It does encrypt just for good measure the last 4 digits of CC numbers in the database.

Because Auth.Net stores the CC data, ARB actually sets up a subscription for ARB referencing that data so it can process payments on time. This involves know necessary communication with the Ubercart site, but Auth.Net will post a payment notification to the Ubercart site through their silent post system. This is the data you need to operate on in your site through a couple of hooks provided by the Authorize.Net module.

Can you clarify what you mean by "Because Auth.Net stores the CC data, ARB actually sets up a subscription for ARB referencing that data so it can process payments on time."?

When we were previously running recurring fee transactions using ARB, I saw no ARB subscriptions set up in the Authorize.net site. Maybe this data is not displayed to the merchant? I would have thought I would see it from the Authorize.net dashboard.

You won't see it from the dashboard, but you can find them under Tools > Recurring Billing > Search ARB Subscriptions. It's a little painful to navigate to every time, but from there just submit the form to see all your subscriptions.

"Because Auth.Net stores the CC data, ARB actually sets up a subscription for ARB referencing that data so it can process payments on time. This involves know necessary communication with the Ubercart site, but Auth.Net will post a payment notification to the Ubercart site through their silent post system. This is the data you need to operate on in your site through a couple of hooks provided by the Authorize.Net module."

So, what is the process in the case that the seller or customer wants to cancel a recurring payment? If the recurring payment is canceled in Ubercart is that information passed along to Auth.net?

Yeah, customers or administrators can cancel payments on the UC side, and that will get pushed out to Auth.Net. This is working just fine. The problem is more the communication from Auth.Net to UC and trying to keep synced up with when payments are coming due, what cards are about to expire, etc.