Authorize.net ARB

Can anyone explain WHY GravityForms handles ARB this way?

I understand it's important to verify the credit-card in real-time, at the moment the ARB Subscription is created. But doing that with an AIM Capture transaction, and actually charging the initial payment via AIM (instead of ARB), causes two problems:

1) This one initial payment will be separate from all the subsequent recurring transactions for the Subscription (in a different area of the AuthNet Merchant Interface, i think). And these must then be tied together, by some shared field, like an Invoice Number, Customer ID, or Email Address.

2) Some ARB Subscription data will seem wrong. For example, a subscription purchased today (Feb 12), should have a Start Date of Feb 12, but instead ARB shows Mar 12. That's not really correct. GF shifts the Start Date because we already got the initial payment, so we don't want to charge for it twice. It might also confuse the number of occurrences. But this could be confusing for the merchant (and customer, if there's a client-portal on the site).

Instead of these problems, why not just use the AIM Auth-Only transaction, to verify the credit-card at the moment the ARB Subscription is created. Then the first charge will be done -- by ARB, not by AIM -- the very next day (at 2pm PST).

Just wondering about the benefit of the GravityForms approach, so I can explain the problems to my client.

HI Alex. Thanks for taking this feedback into consideration. As your team brainstorms, I'd like to offer another ARB issue to consider -- how the AuthNet Feed specifies the Cycle for the entire form.

Currently, all entries from a form must have the same Cycle (1 month, 12 months, etc). So the form can't have a field that allows the user to select the Cycle (and perhaps adjust the price accordingly, for a discount on annual subscription vs monthly).

I used a hook to adjust the cycle, based on the value of my Payment Cycle field (radio-buttons for Monthly and Yearly). Alternatively, I think we could just use separate forms for each Cycle, and require the user to make that selection as a preliminary step, prior to seeing the main payment form. But that's a pretty awkward user-experience, and more confusing for the site-owner to setup and maintain. It'd be great if the cycle could be set by a field (perhaps a new field in the Pricing group), rather than the AuthNet feed.

To repeat bartoncollege's issue above, we're now seeing the exact same problem happening with almost all ARB transactions processed by the authorize.net add-on and the latest version of GF. It looks like this has been happening since the release of 1.7.5. I can't find any version history or older version of GF to revert back to and i think this is a crucial issue that should be fixed ASAP!

The error code customers keep getting:
The credit card expires before the subscription start date. Please use another form of payment.

Authorize.net has this listed in their documentation:
API Error Code: E00018
Error Code Text: The credit card expires before the subscription startDate.
Description: The credit card is not valid as of the start date of the subscription.

Authorize.net support has informed us that something isn't right in the way the form is processing the data and how it interfaces with their API

@Alex Cancado: Any update as to when this might be fixed? We're still seeing this issue and customers are getting pretty ticked off about having their cards charged multiple times.

Alternatively, the older version of your add-on worked flawlessly, but you guys have no changelogs or older version repository anywhere. Any chance i can get access to older versions of this add-on?